test(ingestor): wait for async tx_last_seen backfill before seeding

[dborup]

Problem

TestBackfillTxLastSeen_ResolvesFromMaxObservationTimestamp fejlede intermitterende med last_seen = 100, want 300 (bl.a. merge-CI run 35107538732 efter #57; også dokumenteret i #17, #33 og #52).

Årsag: newTestStore → OpenStore starter den automatiske async migration tx_last_seen_backfill_v1 (cmd/ingestor/db.go:211). Testen seeder derefter transmissionen og observationerne 100, 300, 200 som separate auto-commits. Når baggrunds-backfillen kørte midt i seedingen, læste den de delvist indsatte testdata og satte last_seen = 100. Backfillen vælger kun rækker med last_seen = 0 (db.go:262), så testens eget, direkte backfillTxLastSeen-kald sprang rækken over.

Rækkefølgen er vist med midlertidig instrumentering i en isoleret diagnosekopi (ikke en del af denne PR): i 10/10 fejlende kørsler committede baggrundskørslen last_seen=100 efter observation 100 og før 300, og den kørte stadig, da testen læste værdien.

Rettelse

Kun testfixture-synkronisering — ingen produktionsændringer, ingen ændring af den fælles newTestStore-helper:

• De fire eksisterende TestBackfillTxLastSeen_* kalder store.WaitForAsyncMigrations() straks efter newTestStore(t), før de seeder data eller ændrer de package-globale txLastSeenBackfillBatchSize/txLastSeenBackfillYield. Det er den eksisterende ventemekanisme (backfillWg), som dækker begge async migrations fra OpenStore.
• Alle eksisterende assertions er uændrede. Ingen sleeps, retries eller skips.

Ny regressionstest

TestBackfillTxLastSeen_PartialClaimHealedByObservationBump låser den invariant fast, som last_seen = 0-filteret bygger på:

1. Etablerer deterministisk last_seen = 100 via backfill (og asserter det).
2. Indsætter en observation med timestamp 300 for samme hash via den faktiske InsertTransmission-kodevej.
3. Kræver last_seen = 300.

Ingen baggrundstiming bruges til at fremkalde tilstanden.

Mutationstjek (tidligere kørt, ikke genkørt her): i en scratch-kopi blev stmtBumpTxLastSeen deaktiveret (... AND 0). Den nye test fejlede 3/3 på den forventede slut-assertion (last_seen = 100, want 300); de øvrige fire tests bestod. Mutationen er ikke med i denne PR.

Verifikation

Alle lokale resultater er macOS arm64, go1.26.0 (GOTOOLCHAIN=local), på eksporter af de præcise træer, med ydre tidsgrænser.

Friske kørsler på denne PR's HEAD (14789759):

• Testfamilien ^TestBackfillTxLastSeen_: 10/10 bestået normalt; 5/5 bestået under -race, 0 race-advarsler.
• go vet .: ren. gofmt -l: ren. git diff --check: ren.

Tidligere kørsler (samme indhold, ikke genkørt):

• Candidate, testfamilien: 100/100 bestået normalt; 50/50 under -race, 0 race-advarsler.
• Baseline aac4fae2, testfamilien: 38 bestået / 12 fejlet af 50 (alle last_seen = 100, want 300).
• Hele ingestor-suiten med CI-kommandoen (go test -count=1 -timeout 20m -coverprofile=… ./...), 3 skiftevise kørsler: baseline 2 ok / 1 fejlet (samme assertion); candidate 3/3 ok.

Uafhængigt review (reviewer, der ikke implementerede rettelsen) bestod uden blockers.

Begrænsninger og åbne spørgsmål

• Linux/amd64 er endnu ikke verificeret. CI-fejlen er set på ubuntu-24.04 / go1.27.1 linux/amd64, men alle lokale resultater ovenfor er fra macOS. CI på denne PR er den første Linux-evidens.
• Watchdog-flaken er separat og ikke rettet: TestMQTTStallWatchdog_DisconnectedEscalationThrottled_1749 fejlede én gang i en tidligere lokal baseline-kørsel (got 2 invocations). Den er ikke undersøgt her.
• Serverens observations-writer er fortsat uafklaret: cmd/server/routes.go indsætter observationer uden at opdatere transmissions.last_seen. Den er ikke undersøgt eller ændret. Denne PR frikender ikke alle produktionsskriveveje, og det er ikke udelukket, at den vej kan efterlade en forkert (også ikke-nul) last_seen.
• Andre tests, der seeder data direkte efter newTestStore, kan potentielt have samme type race; det er ikke gennemgået i denne PR.

🤖 Generated with Claude Code