fix(webapp): show the toast when saving project general settings

[claude]

Requested by Chris Arderne · Slack thread

Related to #4324

Before / After

Before: an org member without project-manage permission renames a project on the general settings page, hits Save, and lands on the tasks page with no message at all. The code intends to show "You don't have permission to rename this project", but nothing appears — the rename silently does nothing. The same silence applied to a successful rename: the "Project renamed to ..." toast never showed either.

After: you stay on the general settings page you submitted from, and the toast explains what happened — either the permission error or the rename confirmation.

This makes the reason visible; it does not change who is allowed to rename a project.

Why the message disappeared

The toast is a flash value in the __message cookie. The root loader (app/root.tsx) reads it with session.get("toastMessage") — which deletes the flash — and commits the emptied session on the same response. So the message survives exactly one hop that runs the root loader.

These redirects pointed at the project root, /orgs/:org/projects/:project. That route's _index loader doesn't render anything; it immediately redirects again to the environment's tasks page. On a client navigation Remix fetches every matched route's loader in parallel, so the root loader ran for that intermediate hop, spent the flash, and returned a Set-Cookie clearing it — and then the router threw that hop's data away because a sibling loader redirected. By the time the tasks page rendered, the cookie was already empty.

Ruled out along the way: the Set-Cookie is not dropped on the action's redirect, shouldRevalidate is not blocking the reader, and nothing swallows the thrown Response.

Worth knowing generally: any redirectWithSuccessMessage / redirectWithErrorMessage whose target is itself a redirecting route loses its message for this reason, since the flash is read and cleared on a hop that renders nothing. Other call sites are likely affected. Fixing the class properly — forwarding the Set-Cookie through internal redirects, or reading the flash somewhere other than root — is a bigger architectural change than this PR should carry, so it deliberately stays out of scope: this PR only fixes the call sites in this one route.

How

redirectWithErrorMessage / redirectWithSuccessMessage in the general settings action now target v3ProjectSettingsGeneralPath(...) instead of v3ProjectPath(...). That removes the intermediate redirect hop entirely, so the very next request renders the toast.

Redirecting back to the form is also the better behaviour on its own terms — a save that fails shouldn't move you off the page you were working on. The alternative fixes were worse: reading the flash somewhere other than root would need the toast plumbing rewritten for one call site, and having the project _index loader forward the cookie would leave the same trap set for every other caller that redirects through it. redirectDocument() was considered (per #4146's sibling fix for stale route chunks) and isn't relevant here — the settings route is already loaded, and this was never a chunk-loading failure.

Applied to all four project-root redirects in the file: rename denial, rename success, delete denial, and delete failure.

Delete success has the same defect and is deliberately left alone. It redirects to the org root /orgs/:org, whose _index loader has no branch that renders — every path throws a redirect — so "Project deleted" is swallowed the same way. The project you'd return to no longer exists, and there is no org-level page that both renders and makes sense to land on after a delete (the org has no projects list; the only rendering org pages are the settings subtree, "new project" and invites). Relocating where people land after deleting something is a worse trade than a missing confirmation, so the destination stays as it is and the release note doesn't promise a message for deletion.

The default-region action in …env.$envParam.regions/route.tsx was checked — it already redirects to regionsPath(...), its own rendering page, so it never lost its message and is unchanged.

The other silent path

With the redirects fixed, the two json({ errors: { body: … } }) returns were the only remaining way to fail this form with nothing on screen. That shape isn't a conform SubmissionResult, so when it reached useForm({ lastResult }) conform called reset() and threw the message away: blank form, no error, submit re-enabled. Both now return json(submission.reply({ formErrors: [...] })), and the rename form renders renameForm.errors the way the delete form on the same page already did.

The as any on useActionData() stays. dashboardAction is generic over TReturn extends Response, so useActionData<typeof action>() resolves to unknown and the cast is the only thing keeping it compiling. Removing it properly means teaching the shared route builder to carry its handler's payload type, which would touch every route using it.

---

✅ Checklist

• I have followed every step in the contributing guide
• The PR title follows the convention.
• I ran and tested the code works

---

Testing

New test at apps/webapp/test/projectSettingsToastRedirect.test.ts, four cases:

1. Drives the real redirectWithErrorMessage and the real cookie session storage through the two-hop chain and asserts the message is present on the first hop and gone on the second — the reproduction of the bug.
2. and 3. Drive the route's real action for a denied rename and a denied delete, asserting both the redirect Location and that a root-loader-style read of the resulting cookie yields the expected message.
3. Pins the successful-delete destination at the org root, so the deliberate trade above doesn't drift unnoticed.
4. Drives a failing rename and asserts the response is a conform SubmissionResult carrying the form-level error, so the message actually reaches the form.

Cases 2 and 3 fail against main (expected '/orgs/o/projects/p' to be '/orgs/o/projects/p/env/prod/settings/general') and pass with this change.

To be clear about what that does and doesn't cover: these tests drive the real redirectWithErrorMessage, the real cookie session storage and the route's real action (the auth gate and ProjectSettingsService are mocked, as in the existing route tests). I have not clicked through a running dashboard — the redirect target and the cookie lifecycle are what's verified here.

Test Files  1 passed (1)
     Tests  5 passed (5)

Also run: pnpm run typecheck --filter webapp (19/19 tasks pass), pnpm run lint --filter webapp (clean — 7 pre-existing warnings, unchanged from main) and pnpm exec oxfmt --check . (clean).

---

Changelog

Renaming a project now keeps you on the project settings page and tells you what happened, instead of silently moving you to the tasks page or clearing the form with no explanation.

---

Screenshots

None — the change is a redirect target; the toast component itself is unchanged.

💯

[changeset-bot]

⚠️ No Changeset found

Latest commit: 617296a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[trigger-dot-bot]

Preview Deployment

Status	Preview	Commit	Updated
⚪ Removed	–	617296a	Aug 13, 11:23 UTC

[devin-ai-integration]

Devin Review found 2 new potential issues.