When code runs with concurrent rendering and async workflows, ensure any async/derived value that can affect what gets rendered (or how consumers behave) is deterministic per concurrent “world”, and make promise behavior explicit.
Apply these rules:
1) Don’t use refs for render-visible concurrency state
- If a mutable value is read by render (directly or via context consumers) to decide which queries/results are active, store it in state (or another render-consistent mechanism), not a mutable ref.
- This avoids cross-tree leakage where concurrent renders expect different values.
2) Make enable/disable transitions deterministic
- Define what should happen to in-flight work when
enabled toggles (e.g., reuse the same promise, or deterministically reject when disabled).
- Add tests that assert the exact expected promise/reuse behavior.
3) Be explicit about awaiting vs fire-and-forget
- In tests or code paths where you intentionally don’t wait for an async operation, explicitly discard the promise:
void queryClient.resumePausedMutations()
- If you need completion ordering, await it intentionally.
4) Treat CI-only failures as race-condition signals
- If tests intermittently fail, suspect async timing/races.
- Stabilize tests by awaiting the right signals (not arbitrary delays) and ensuring promise lifecycle/enablement semantics are exercised deterministically.
These practices prevent incorrect hydration/selection during concurrent rendering, clarify async semantics, and reduce flaky test outcomes caused by nondeterministic scheduling.