[ac-pplx]

Summary

Org and user detail pages now say when the object does not exist, instead of rendering a blank page.

Changes:

• /dashboard/orgs/{id} and /dashboard/users/{id} never handled a failed load. An unknown or deleted ID left an empty content area and an uncaught promise rejection (resource not found) in the console. Both pages now show "Organization not found" or "User not found" for a 404, with the API's message, the ID and a link back to the list. Any other failure (a 500, a 403, a network error) shows "Could not load the organization" or "Could not load the user" with the error and a Retry.
• Saving branding on the org page had no error handling. A failed PATCH /admin/api/v1/orgs/{id} produced an unhandled rejection and no message. It now reports the API's error, and the button shows progress while the save runs.

Stack

Not stacked on anything. #1253 (user page) is stacked on this PR, and #1262 on #1253.

Validation

• At this head, in ui/: npm ci, npm test (144 pass, including src/lib/load-failure.test.mjs), npx tsc --noEmit -p . and npm run build.

• A Playwright loop against a local Kind stack with synthetic data, run on main (production build) and on this branch (the Kind space-ui image):

  • unknown org and user IDs show their not-found states, and the page errors seen on main are gone;
  • a branding save forced to fail (Playwright returns a synthetic 500 for the PATCH) shows an error message;

• No new console errors, page errors or failed requests compared with main.

• A loop step answers the first org or user GET with a synthetic 500 (route interception): the page reads "Could not load the organization" (or "the user") with Retry instead of "not found", and Retry loads the page.

Visual confirmation

Before (main)	After

Severity and risk

Severity: low. These are error paths, but on them an operator saw nothing and could not tell an unknown ID from a broken page.

Risk: low. The successful paths are unchanged. Roll back by reverting the commit.

AI assistance: Claude Code wrote the code and this description, and ran the validation; a maintainer reviews it.

[github-actions]

Thanks for opening this pull request! A SPACE maintainer will take a look.

CONTRIBUTING.md explains how we review outside contributions.

Withdrawing this approval for now. Any feedback above still stands.

[ac-pplx]

Rebased onto main (new head 8f0f82f); it had conflicted in sandbox-detail.tsx.

The conflict was this PR's "stop polling a sandbox after its first 404" change. main now keeps polling after a 404 on purpose: while the sandbox's create operation is still queued or running, the page shows "Sandbox is being created" and loads the sandbox as soon as it exists. Stopping the poll would break that, so the rebase keeps main's handling and drops the change, from the first commit's message and from the description too. The PR now changes only the organization and user pages.

#1253 and #1262, stacked on this PR, were restacked with their commits unchanged. At each of the three heads, in ui/: npm ci, npm test (144, 151 and 151 pass), npx tsc --noEmit -p . and npm run build all exit 0.

[johnlouie-pplx]

Approving.

I compared 8f0f82f with the head I reviewed before. The only change is dropping the sandbox page's stop-polling-on-404, which is the right call now that main keeps polling while a create is pending. The sandbox page on main also uses the same rule now (404 is "not found" with no retry, anything else is "Could not load" with Retry), so all three detail pages agree. I ran npm test (144 pass) and tsc on this head. I didn't run it in a browser.