## 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?
In the SQL Editor, when two snippets are both named "Untitled query" and
one is renamed, the rename modal's state is not reset afterwards.
Opening the rename modal for the second snippet prefills the input with
the first snippet's new name, and the second snippet can't be renamed at
all because the "Rename query" button stays disabled.
`RenameQueryModal` fed the snippet to react-hook-form through the
`values` option, which only re-runs its reset when the values object
deep-changes. Two snippets with the same name (and no description)
produce a deep-equal object, so switching between them never resets the
form — it keeps the previously renamed name and stays non-dirty.
## What is the new behavior?
The form is mounted per snippet (`key={snippet.id}`) with plain
`defaultValues`, so no form state can carry over between snippets
regardless of name collisions. `SQLEditorNav` derives modal visibility
from the selected snippet and clears it on cancel/complete, matching
`SearchList`.
Covered by a new component test in `RenameQueryModal.test.tsx` that
renames one "Untitled query", reopens the modal for a second one, and
asserts the field resets and the second rename submits.
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Fixed the rename dialog retaining input from a previously renamed
snippet.
* Ensured the rename form resets correctly after successful submission
and when switching between snippets.
* **Tests**
* Added regression coverage for renaming multiple untitled snippets with
the same original name.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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 -->
Charis