## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Bug fix
## What is the current behavior?
The SQL snippet rename modal is mounted once per nav and reused for
every snippet, so a single form instance is shared across renames. On a
successful rename the form was never re-baselined, leaving it dirty, and
the effect that synced the form to the selected snippet bailed out
whenever the form was dirty.
Renaming a second snippet therefore opened the modal pre-filled with the
previous snippet's name, with the submit button enabled — one careless
confirm renamed the wrong query.
## What is the new behavior?
The form is reset after a successful rename, and the hand-rolled sync
effect is replaced with react-hook-form's `values` option so the form
follows whichever snippet is selected.
`keepDirtyValues` keeps a background refetch from clobbering in-progress
input, which is what the old dirty guard was protecting against. It has
to be disabled explicitly on the resets that discard input, since
`resetOptions` on `useForm` applies to every `reset` call — not just the
`values`-driven one.
Adds component tests covering the submit path, the rename-then-rename
regression, and discarding an abandoned edit on cancel.
## Additional context
Fixes FE-4114
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- Improved the rename query experience by ensuring the selected snippet
name is displayed correctly when reopening the rename dialog.
- Cancelled edits are now discarded reliably, preventing unsaved changes
from persisting.
- After a successful rename, the form reflects the updated query name
and maintains consistent input and button behavior.
- **Tests**
- Added coverage for successful renaming, cancellation, reopening with a
newly selected snippet, and submitted values.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
