fix(seeders): self-healing TTLs for military-bases version keys (#6845 item 1)

[yzxcj797]

First follow-up from #6845: a run killed before atomicSwitch leaks its version keys permanently.

Mechanism

The seeder writes military:bases:geo:<version> / meta:<version> with no TTL, and cleanupOldVersion only ever computes keys from the version that is currently active — a version that never published is swept by nothing, ever. The runner SIGTERMs at timeoutMs and SIGKILLs 10s later, so each such death leaks up to a 125,380-member zset plus a 125,380-field hash. The same hole leaks the superseded version when a run dies inside the 30s grace: the DELs never fire, and the next reseed deletes only the then-active version.

Fix — three cooperating halves

1. Seeding arms a self-healing TTL on every batch. seedGeo/seedMeta piggyback EXPIRE key 1800 onto each pipeline: it arms from the first write (EXPIRE on a missing key is a no-op) and keeps refreshing while the run is alive — only a dead run lets it count down. 30 min is ~3× the 540s slot incl. the R2-cold worst case, so a slow-but-alive run can never expire its own data.
2. atomicSwitch PERSISTs inside the publish EVAL. The version's own two keys are passed as KEYS[3]/KEYS[4] and PERSISTed atomically with the SETs — a published version can never expire, an unpublished one always can.
3. armSupersededCleanup right after the switch. The old pair gets EXPIRE 150s (5× the reader grace) after atomicSwitch lands — deliberately not before, because until the switch they ARE the live data and seeding can outlast any superseded TTL. A kill inside the grace window now self-heals: Redis reaps them shortly after the grace would have ended.

Plus a best-effort start-of-run sweep (sweepLeakedVersionKeys) that heals historical leaks from pre-TTL runs: SCAN both key families; a key counts as leaked only when TTL == -1 and it is not the active version's. Live seeding runs and the active version can never match. The sweep never DELs — it only re-arms the superseded TTL and lets Redis reap, preserving a grace-sized window even if a concurrent publish flips active mid-scan. Transport failure logs a warning and moves on; the next run sweeps again.

Tests

Six new tests in tests/seed-military-bases-version-key-ttl.test.mjs:

• TTL constants bracket their windows (version TTL ≥ 10 min > slot; superseded TTL ≥ 2× grace)
• seedGeo/seedMeta arm + refresh the EXPIRE on every batch
• atomicSwitch EVAL: numkeys 4, both version keys, PERSIST for both, payload last
• armSupersededCleanup EXPIREs exactly the two old keys
• the sweep re-arms only no-TTL non-active keys (TTL-armed and active keys untouched; active excluded by name before any TTL probe)

tests/bundle-runner.test.mjs's publish-contract test is updated for the 4-key EVAL shape and now also asserts the two PERSIST calls and the geo/meta key names. All green locally (6/6 new, 38/38 bundle-runner, 9/9 existing seeder tests).

[vercel]

@yzxcj797 is attempting to deploy a commit to the World Monitor Team on Vercel.

A member of the Team first needs to authorize it.

[cursor]

Review — head 5f61ed00d

The seeder work in this PR is healthy. Both blockers come from a commit that belongs to a different PR.

Blocker 1 — this branch carries #6870's commit, and that is what reds unit

The branch is two commits, and the first is not yours-for-this-PR:

698e72707 perf(prepush): fetch only to disprove a suspected contamination violation (#6764)
5f61ed00d fix(seeders): self-healing TTLs for military-bases version keys (#6845 item 2)

That first commit is why .husky/pre-push, tests/prepush-hook-gate.test.mjs and tests/bundle-runner.test.mjs appear in a seeder PR's file list, and it is the source of the CI failure:

✖ a stale-ref false positive still fetches, disproves itself, and passes
  AssertionError: cached count 26 > 20 must fetch exactly once to recompute
    actual: 2, expected: 1
  at tests/prepush-hook-gate.test.mjs:606

Reproduced locally on an exported head tree. It is a harness defect, not a hook defect. The test's own setup at :599 runs a fetch through the fixture:

fixture.git(['fetch', '--quiet', 'origin', 'main:refs/heads/__remote-main']);

That lands in the same git-invocations.log that fetchCount(gitCalls) later counts, and run() only clears the log after reading it (:188-189), never before. So the assertion sees the setup fetch plus the hook's one real fetch. Clearing both logs at the top of run() (:172) fixes it:

const run = (extraEnv = {}) => {
  rmSync(log, { force: true });
  rmSync(gitLog, { force: true });
  …

With that, the file is 21/21 green. #6870 is red on the same test for the same reason, so the fix belongs there.

Blocker 2 — the conflict is also from the stacked commit

git merge-tree origin/main <head> reports exactly one conflicted file: tests/prepush-hook-gate.test.mjs. Nothing in scripts/seed-military-bases.mjs conflicts.

Recommendation: drop 698e72707 from this branch. Both blockers disappear with it, this PR becomes a clean single-commit seeder change, and #6870 keeps its own timeline and its own fix. As a bonus, #6875 also edits tests/prepush-hook-gate.test.mjs, so keeping the prepush work in one place avoids a three-way tangle.

The seeder change itself is sound

• tests/seed-military-bases-version-key-ttl.test.mjs → 6/6 pass, covering the four behaviours that matter: seedMeta arms and refreshes the TTL on every batch, atomicSwitch PERSISTs the version keys inside the publish EVAL, armSupersededCleanup EXPIREs both old keys for the superseded window, and the sweep re-arms TTLs only on no-TTL, non-active version keys.
• Non-vacuous: swapping scripts/seed-military-bases.mjs back to its merge-base version reds the file immediately.
• Doing the PERSIST inside the publish EVAL is the right call — it keeps "this version is now active" and "this version's keys no longer expire" in one atomic step, so a crash between them cannot leave the live version on a countdown.

Coordination note

scripts/seed-military-bases.mjs is being edited by three open PRs at once — this one (TTLs, atomicSwitch/seedMeta), #6872 (no-data fallback in main()), and #6873 (activation marker in maybeRepairMissingSeedMeta and main()). They touch adjacent regions and do not conflict yet, but whichever lands second and third will need a rebase. Worth deciding an order.

Verdict: blocked, but only on the stacked commit. Drop 698e72707 and the seeder work is mergeable.

[koala73]

Review (not ready)

CONFLICTING, and unit/gate are red. This head also looks contaminated with #6870 pre-push hunks.

Please rebase onto current main as a TTL-only change, drop unrelated pre-push edits, and re-run unit.

[koala73]

@yzxcj797 pls don't forget this one - you are churning a lot of PRs, but I want to close the older ones first

Reviewed