Sites pane on Organizations & Sites page follows top-bar org switcher instead of in-page selection

[bdunncompany]

Reproduction

1. Top-bar org switcher set to org A
2. Settings → Organizations & Sites
3. Click org B in the left list

Result: the right pane heading shows "B" (correct), but the Sites table shows org A's sites.

Root cause

OrganizationsPage.fetchSites (apps/web/src/components/settings/OrganizationsPage.tsx:114) calls:

fetchWithAuth(`/orgs/sites?organizationId=${orgId}`)

fetchWithAuth (apps/web/src/stores/auth.ts:268-275) auto-injects orgId=<currentOrgId> from useOrgStore whenever the URL does not already contain the literal substring orgId=. Since the page uses the alias organizationId=, the injector does not see it and appends &orgId=<top-bar-org>.

The API (apps/api/src/routes/orgs.ts:921-924) then resolves:

const effectiveOrgId = orgId || organizationId;

orgId (the auto-injected top-bar value) wins over organizationId (the in-page selection), so the server returns sites for the top-bar org. The page heading is local React state and stays correct, which makes the divergence hard to notice in code review.

The bug only surfaces when the top-bar and in-page selections disagree. Most callers happen to use both contexts equal, which is why this slipped.

Proposed fix

One-line change: have OrganizationsPage.fetchSites use the orgId= param name directly. The injector will see it and skip re-adding the top-bar context.

-fetchWithAuth(`/orgs/sites?organizationId=${orgId}`)
+fetchWithAuth(`/orgs/sites?orgId=${orgId}`)

Optional hardening (separate PR): apply the same rename to orgStore.fetchSites (apps/web/src/stores/orgStore.ts:172) for consistency, even though that path happens to be benign today.

Test: Vitest unit test that mocks fetchWithAuth, sets useOrgStore.currentOrgId to a different value than the in-page selection, and asserts the captured Sites request URL contains the in-page org's id (not the top-bar's).

Happy to open the PR if this looks like the right shape.

[ToddHebebrand]

Thanks @bdunncompany — confirmed. The organizationId= alias slipping past the orgId= substring check in fetchWithAuth, combined with the API's orgId || organizationId precedence, is exactly the divergence. Green light on the one-line fix.

One preference: fold the orgStore.fetchSites rename into the same PR. It's benign today only by coincidence (top-bar and in-page orgs happen to agree on that path), and leaving one caller on the organizationId= alias keeps the foot-gun loaded for the next person. Same trivial diff, one consistent param name everywhere.

The Vitest test you described — useOrgStore.currentOrgId set to a different value than the in-page selection, assert the captured request URL carries the in-page org id — is the right guard. Please cover both call sites.

Open as a draft and I'll review.

[bdunncompany]

Draft PR up at #712. Both call sites renamed; both covered by tests (orgStore.fetchSites assertions updated; new OrganizationsPage.test.tsx asserts the captured Sites URL contains the in-page org id and does NOT contain organizationId=).

[ToddHebebrand]

Resolved on main. Your root-cause was correct — the organizationId= alias slipping past the orgId= substring check in fetchWithAuth, combined with the API's orgId || organizationId precedence.

The fix landed via #732 (8c29c817), which corrected it at the API layer (/orgs/sites now honors an explicit organizationId over the ambient orgId). Your PR #712 forked before #732 landed and was closed as superseded — but the analysis in this thread is what pinned the bug down.

Thanks @bdunncompany. Closing as resolved — reopen if the Sites pane still diverges from the in-page selection on current main.