[maxidragon]

Problem

TC-TT-017 ("No access to a project … the request-access action works") fails intermittently in ephemeral-integration shard 12, on develop and on unrelated PRs (#140 failed it on four attempts in a row). The cause is a real UI bug, not the test.

After a time-tracking project page mounts, the organization switcher resolves the scope and emits a scope change. That bumps useOrganizationScopeVersion(), and the project pages reload the project. Every reload went through the full-page loader, which unmounts whatever was on screen:

• On the no-access guard (screen 17), "Request sent" flips back to an enabled "Request access" once the reload lands after the click. The user is invited to send a request they already sent. On a slow runner the reload does land after the click: in the failing run's Playwright trace, the access-requests POST is followed by the organization-switcher GET and then a second time-projects GET, and the failure screenshot shows the reset button.
• On the edit page, the same reload would unmount the CrudForm and drop unsaved edits.

Solution

The reload that raced the click is the first scope settlement. The scope version starts at 0 and only increases on a real change, so a screen resolved under version 0 was loaded before the switcher first settled the scope. That screen now stays up through the reload and swaps in the new answer when it arrives.

A switch between two known scopes (version ≥ 1 → next) still goes through the full-page loader as before. Nothing loaded for the previous organization or tenant stays on screen or clickable.

• Detail and edit pages: the load effect no longer resets loading/accessDenied/isNotFound/error up front. It settles all of them together once the answer arrives. Each load is recorded as it starts, and the loader is skipped only when the load it replaces was for the same project at scope version 0. The replaced load counts even if it never finished, so a version-0 load cancelled by a quick second switch can't let that switch through.
• Board page: the scope version is part of the react-query key, so the scope settling re-keys the query. placeholderData keeps the previous answer, but only when it came from scope:0 for the same project.

If the reload's answer differs, for example because the settled scope does grant access, the screen still updates to it. Only the blank-loader flash between the two answers is gone.

Verification

• New projects/[id]/__tests__/page.accessRequestScopeReload.test.tsx (detail page) has three cases:
  • First settlement (version 0 → 1): the project reloads and "Request sent" stays disabled. This case fails on the old page ("Unable to find … button 'Request sent'").
  • Known-scope switch (1 → 2): the page goes through the loader and comes back without the previous scope's state. This case fails if the version-0 condition is removed.
  • Cancelled first settlement: the page settles at 0, the version-1 load is held in flight, and the scope switches to 2. The loader must come back. This case fails if the decision is made from the last settled load.
• New projects/[id]/board/__tests__/page.accessRequestScopeReload.test.tsx (board page) covers the same two paths as the first two cases, through react-query. Removing placeholderData fails the first case, and dropping the scope:0 condition fails the second.
• npx jest "time-tracking/projects|no-project-access" in packages/core: 12 suites, 39 tests, all passing.
• ESLint is clean on the changed files. tsc reports nothing new in them: the only errors are the missing generated registries in a fresh checkout.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[Copilot]

Copilot review overview

🟡 Changes recommended

The retention logic can expose and leave actionable project data from the previous organization or tenant during a genuine scope switch.

Review effort: Balanced
Findings: 3

Open (3)

• Prevent cross-scope project data placeholder reuse · New
• Reset edit form when organization or tenant scope changes · New
• Clear detail view on organization or tenant scope changes · New

What changed in this PR

Prevents background scope reloads from unmounting project screens and losing local UI state.

Changes:

• Preserves detail and edit screens during same-project reloads.
• Retains board query data while its scoped query refreshes.
• Adds regression coverage for access-request state.

File	Description
projects/​[id]/​page.tsx	Preserves resolved detail state during reloads.
projects/​[id]/​edit/​page.tsx	Keeps the edit form mounted during reloads.
projects/​[id]/​board/​page.tsx	Uses scoped query placeholder data.
projects/​[id]/​__tests__/​page.accessRequestScopeReload.test.tsx	Tests access-request state retention.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[blacksmith-sh]

Found 2 test failures on Blacksmith runners:

Failures

Test	View Logs
src/modules/progress/tests/progressService.test.ts/ markCancelled — broadcasts the flushed row rather than the pre-flush copy	View Logs
src/modules/progress/tests/progressService.test.ts/ markCancelled — flushes the throttled meta so a producer's partial summary survives the cancel	View Logs

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[jtomaszewski]

Summary

After a time-tracking project page loads, the organization switcher finishes resolving the scope and triggers a reload. Before this PR, that reload always showed the full-page loader, which threw away whatever was on screen. On the "no access" screen, a user who had just clicked Request access saw the button flip back from "Request sent" to an enabled "Request access", inviting them to send the same request twice. This also made TC-TT-017 flaky in CI. On the edit page, the same reload could wipe unsaved form edits.

The PR keeps the current screen up during that first reload, when the scope version goes from 0 to 1, and swaps in the new answer when it arrives. A real switch between two known scopes (version 1 or higher) still goes through the loader, so nothing from the old organization stays clickable.

🔍 Details

• Detail and edit pages: the load effect no longer resets loading, accessDenied, isNotFound and error before fetching. A single settle() sets all four together once the answer is in. A resolvedRef remembers which project and scope version the screen was last resolved under. The loader is skipped only when that version is 0 and the project is the same.
• Board page: the query key already includes scope:<n>. A placeholderData callback returns the previous data only when the previous key was scope:0 for the same project. When the user has no access, that previous data is null, and react-query v5 treats null as a real placeholder. So isLoading stays false and NoProjectAccess stays mounted.
• New test: it covers the detail page for both cases. On the 0 → 1 reload, "Request sent" stays disabled. On a 1 → 2 switch, the page goes back through the loader.

Walkthrough

Keep the resolved screen through the first scope settlement

The detail and edit pages now settle all their status flags in one place, after the fetch finishes. They skip the loader only for the same project resolved under scope version 0. The board page does the same through react-query placeholderData. The thing to check is the condition that decides when a reload counts as a background refresh rather than a real scope switch.

Regression test for the access-request reload

A jsdom test renders the detail page, sends an access request, then bumps the mocked scope version. It covers both the first settlement (the screen is kept) and a known-scope switch (the loader comes back).

---

Reviewed with cerber 🐕 — drafted by AI, sent by a human.

[maxidragon]

Superseded by open-mercato#7132 — this change is now under review upstream. Branch fix/time-tracking-access-request-survives-scope-reload is left in place because it is the head of that upstream PR; deleting it would close the PR.