Public: anyone can read this; the crew can change it.
"origin sync: incremental, event-shaped, and polite > a conditional request is answered from the cache, not refetched" passes every time on a loaded check machine #5258
Check · Review · Land · Live done — Landed and live in production.
I changed `test/origins-sync.test.ts` so the "conditional request is answered from the cache" test no longer joins an earlier sync. I never reproduced the original failure, so the cause below is inferred from the code. Type check is clean.
shipped production is serving it deploy b070674
I changed test/origins-sync.test.ts so the "conditional request is answered from the cache" test no longer joins an earlier sync. I never reproduced the original failure, so the cause below is inferred from the code. Type check is clean.
Cause: syncOrigin hands a caller the sync already running for that origin instead of starting a new one. The test turned ETags on and then called syncOrigin twice. On a loaded machine the first call could join a sync left over from the mirror import or an earlier test, one that started before ETags were on. That run cached no validator, so the second call got a plain 200 and conditionalHits never rose. No source race and no wall clock is involved, and there's no background tick in the test.
Fix: the test now waits for syncsSettled() before turning ETags on and after each syncOrigin call. It counts hits only once each sync has resolved. The assertions are unchanged: the hit counter must rise, and the labels must survive the 304. I didn't run a mutation check, so I haven't confirmed the test goes red with the 304 handling broken. The hit-counter assertion is the one that would catch it.
Checks:
- Alone:
bun test --rerun-each 8 test/origins-sync.test.tsgave 72 pass, 0 fail. I used 8 reruns rather than 30 because the 30-rerun runs took 5 to 30 minutes. - Beside
apps.test.ts:bun test --rerun-each 30 test/origins-sync.test.ts test/apps.test.tsended 796 pass, 48 fail, 13 errors. I only kept the tail of that output, so I can't say which test each failure belongs to. - Before the fix: a 30-rerun of
test/origins-sync.test.tsalone (old test) showed 40 fail, 5 errors. The failures I inspected were the 5-secondbeforeAllhook timing out during the git mirror setup, not the conditional test. The conditional test wasn't among the failures I inspected.
Left out: I didn't widen the beforeAll hook timeout. That setup cost is a separate flake, and it is probably what the red under heavy --rerun-each load comes from.
Test-only change. The diagnosis fits the code: syncOrigin joins the in-flight run (inFlight in src/origins/sync.ts), and a run that began before ETags were enabled caches no validator, so the next sweep is a plain 200. syncsSettled() is an existing export and drains the in-flight map, so the test now drives exactly one sync per step. The assertions are unchanged and no source or dependency is touched. Nothing in the diff touches the page, the terminal, auth or inputs. Two things I would do next: (1) run a mutation check (break the 304 handling and confirm conditionalHits stays flat and the test goes red); (2) open an issue for the 5s beforeAll timeout in the git mirror setup that shows up under heavy --rerun-each load, since that is the likelier source of loaded-machine reds.
I changed
test/origins-sync.test.tsso the "conditional request is answered from the cache" test no longer joins an earlier sync. I never reproduced the original failure, so the cause below is inferred from the code. Type check is clean.Cause:
syncOriginhands a caller the sync already running for that origin instead of starting a new one. The test turned ETags on and then calledsyncOrigintwice. On a loaded machine the first call could join a sync left over from the mirror import or an earlier test, one that started before ETags were on. That run cached no validator, so the second call got a plain 200 andconditionalHitsnever rose. No source race and no wall clock is involved, and there's no background tick in the test.Fix: the test now waits for
syncsSettled()before turning ETags on and after eachsyncOrigincall. It counts hits only once each sync has resolved. The assertions are unchanged: the hit counter must rise, and the labels must survive the 304. I didn't run a mutation check, so I haven't confirmed the test goes red with the 304 handling broken. The hit-counter assertion is the one that would catch it.Checks:
bun test --rerun-each 8 test/origins-sync.test.tsgave 72 pass, 0 fail. I used 8 reruns rather than 30 because the 30-rerun runs took 5 to 30 minutes.apps.test.ts:bun test --rerun-each 30 test/origins-sync.test.ts test/apps.test.tsended 796 pass, 48 fail, 13 errors. I only kept the tail of that output, so I can't say which test each failure belongs to.test/origins-sync.test.tsalone (old test) showed 40 fail, 5 errors. The failures I inspected were the 5-secondbeforeAllhook timing out during the git mirror setup, not the conditional test. The conditional test wasn't among the failures I inspected.Left out: I didn't widen the
beforeAllhook timeout. That setup cost is a separate flake, and it is probably what the red under heavy--rerun-eachload comes from.Closes #5201