Skip to content

A foreign org slug renders the console shell instead of a not-found page #1713

Description

@RhysSullivan

What happens

Opening a console URL whose org slug the signed-in user does not own — /<some-other-slug>/policies — sometimes renders the full authenticated console shell for that URL instead of the not-found page:

  • the sidebar, the org switcher (showing the user's own org), and the Policies page chrome all render
  • the org-scoped query behind the page fails, so the body is a red "Failed to load policies" card with a Retry button
  • the URL still reads /<some-other-slug>/policies

So the user is looking at a workspace they were never taken to, under an address that names an organization they cannot see.

What should happen

A not-found page. This is the stated contract, both in OrgSlugGate's header —

a foreign slug never reaches this gate as "active" on a multi-org host: the server returns no organization for an org the caller can't see, and the shell 404s upstream

— and in the e2e scenario that covers it (e2e/scenarios/org-slug-routing.test.ts):

an unknown slug (/zz-no-such-org/policies) is a wrong address — a not-found page, never a silent redirect into a workspace the URL didn't name

Why it is intermittent

The 404 depends on the shell seeing "no organization" for the URL's slug before it renders. When that resolution lands after the first render, nothing throws notFound() and the shell renders normally — there is no code path that turns an unauthorized org selector into a not-found on its own. OrgSlugGate deliberately does not canonicalize in this case (correctly — that would rewrite a bad URL into a good one), so the URL stays foreign and the page stays broken.

How it showed up

This was the single largest source of E2E flake: 36 of 61 flake-signature shard failures in the two weeks to 2026-08-20 were the one navigation page.goto("/zz-no-such-org/policies", { waitUntil: "networkidle" }) timing out after 30 s. The retrying error card is what kept the network busy, so networkidle never settled and the failure surfaced as a navigation timeout with no hint of a product problem. #1707 bounded that wait; the scenario now fails on the actual assertion, getByText('Page not found'), when the race goes the wrong way.

Reproducing

Sign in, then open /<a-slug-you-do-not-own>/policies. It usually 404s; when it does not, you get the shell described above. On a loaded CI runner it reproduced roughly one run in four.

Notes

Both the e2e scenario and this report use synthetic slugs only.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions