Skip to content

Don't reset submit button loading state right before nav - #3345

Merged
david-crespo merged 2 commits into
mainfrom
form-loading-success
Aug 28, 2026
Merged

Don't reset submit button loading state right before nav#3345
david-crespo merged 2 commits into
mainfrom
form-loading-success

Conversation

@david-crespo

@david-crespo david-crespo commented Aug 21, 2026

Copy link
Copy Markdown
Collaborator

Noticed while doing #3344. Form submit button loading state is true only when the mutation isPending. But there's a brief moment after the mutation completes but before the success nav happens where that's false and the button is on screen. What that looks like is the button flipping back to clickable right before the nav. That's stupid, so I gave every button where it makes sense loading={isPending || isSuccess}. There's some risk we could have a form where that is not appropriate (and there are a couple already — see createNic on the instance networking tab) but it's very easy for agents to get it right. I added a note to AGENTS.md about it.

Before

2026-08-21-project-submit-loading.mp4

After

2026-08-21-project-submit-loading-fixed.mp4

@vercel

vercel Bot commented Aug 21, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
console Ready Ready Preview Aug 28, 2026 9:27pm

Request Review

onDismiss={() => {
setCreateModalOpen(false)
createNic.reset() // clear stale error state
}}

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lack of reset() here was a bug, uncaught in a previous PR where I tried to fix these missing resets.

@david-crespo
david-crespo merged commit 4464677 into main Aug 28, 2026
7 checks passed
@david-crespo
david-crespo deleted the form-loading-success branch August 28, 2026 21:57
david-crespo added a commit that referenced this pull request Aug 28, 2026
Fixes two bugs found while doing #3345:

1. **Silent attach failure in the create-then-attach flow.** In the
unlikely event you create a disk from the storage tab and the subsequent
attach call fails (e.g., the instance started in the meantime), there
was no visible error: the error only rendered inside the attach modal,
which isn't open anymore. You'd get the "Disk created" toast but the
disk just wouldn't be attached. Now it shows an error toast.

2. **Stale error leaking between modal uses.** In that failure scenario,
the error stuck to the shared mutation, so the *next* time you opened
the "Attach existing disk" modal, it displayed the old error from the
create flow before you'd done anything. Now the attach modal's mutation
is its own, created fresh on each open.

Moving the mutation inside its own component means we don't have to do
`reset()`s to avoid holding onto state across different openings of the
attach modal.
david-crespo added a commit to oxidecomputer/omicron that referenced this pull request Aug 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant