Verified against main at 715c52e.
Impact
The Refresh button remains enabled while the initial full-detail request is running. A manual forced refresh and the initial normal request can then resolve out of order. Whichever response finishes last currently writes React state and browser session cache, even if it began earlier; the server likewise uses separate normal/force in-flight keys and lets either completion overwrite the shared full cache.
The older request can therefore replace newer repository data, warnings, auth mode, errors, login state, loading flags, and both browser/server cache entries. This is a request-ordering bug, not a hypothetical network failure: the two requests are deliberately allowed to run concurrently and have no shared generation check.
Concrete code references
Acceptance criteria
- For each dashboard source key, only the newest active request may commit data, error, auth/login state, loading state, or browser cache.
- Starting a manual refresh must cancel or invalidate any older initial quick/full sequence.
- An older normal server load that finishes after a newer forced load must not overwrite the newer full-cache entry.
- Stale unauthorized, error, or success responses must not replace the outcome of a newer request.
- Abort/cancellation remains a silent control-flow event rather than a user-visible dashboard error.
Test expectations
- Add a web test with deferred promises: resolve quick, leave the initial full request pending, trigger Refresh, resolve the forced request, then resolve the older full request and assert the UI and session cache retain the forced result.
- Add equivalent server coverage for normal and forced full loads completing in reverse order.
- Cover stale unauthorized/error completion as well as stale success.
- Run both Vitest projects and
npm run check under Node 24.18.0.
Dependencies / order
No hard dependency. Prefer landing this before progressive-loading presentation work so the UI state being presented has a deterministic owner.
Non-goals
- Disabling Refresh for the entire session as a substitute for request ordering.
- Changing the dashboard HTTP response shape.
- Introducing a global request queue across users.
- Reworking GitHub aggregation or scan depth.
Verified against
mainat715c52e.Impact
The Refresh button remains enabled while the initial full-detail request is running. A manual forced refresh and the initial normal request can then resolve out of order. Whichever response finishes last currently writes React state and browser session cache, even if it began earlier; the server likewise uses separate normal/force in-flight keys and lets either completion overwrite the shared full cache.
The older request can therefore replace newer repository data, warnings, auth mode, errors, login state, loading flags, and both browser/server cache entries. This is a request-ordering bug, not a hypothetical network failure: the two requests are deliberately allowed to run concurrently and have no shared generation check.
Concrete code references
refreshing, not whileupdatingDetailsis true.Acceptance criteria
Test expectations
npm run checkunder Node 24.18.0.Dependencies / order
No hard dependency. Prefer landing this before progressive-loading presentation work so the UI state being presented has a deterministic owner.
Non-goals