fix(settings): clear revealed DB connection DSN when switching DB nodes - #356
Merged
Merged
Conversation
Follow-up to #355. Revealing a connection string on the DB Settings pane left the DSN in useRevealedRow state for 30s while the pane retargets in place, and the row key was connection.id (private/public) — identical across every DB Service. Switching nodes within the reveal window made the next DB's connection row display (and copy) the previous DB's full DSN. Scope the settings rows' keys by workload identity so a reveal can never match another DB's row, and clear the revealed row when the identity changes (useRevealedRow now exposes clearRevealedRow) so the secret does not linger in state after the switch.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Follow-up to #355, found in product testing: reveal the connection string on one DB's Settings pane (the eye on a Connection Address row), then switch to another DB node — the new DB's connection row still displayed (and copied) the previous DB's full DSN.
Root cause
Two conditions in the DB Settings connection rows:
useRevealedRowkeeps the revealed DSN forREVEAL_DURATION_MS(30s) and its state lives inuseDatabaseSettingsSections, which is reused in place when the pane retargets (fix(settings): revalidate DB resource claims when switching DB nodes #355 made the pane retarget correctly, but reveal state still carried over).getDatabaseNodeConnectionKey→connection.id→"private"/""public""— identical across every DB Service, so the stale reveal matched the next DB's row.Fix
${namespace}/${name}:private) so a reveal can never match another DB's row.useRevealedRownow exposesclearRevealedRow;useDatabaseSettingsSectionsclears the revealed row when the workload identity changes, so the secret is dropped from state at the switch instead of lingering for the rest of the 30s window.Testing
New regression test in
db-settings-node-switch.test.tsx: reveal the postgres DSN → switch to redis → the postgres DSN must not render (the row falls back to its mask); revealing on redis resolves the redis DSN. Verified it fails onmainwith "the postgres DSN must not render on the redis pane" and passes with the fix.Also added explicit unmounts to the pane tests (the revealed-DSN tooltip tree was leaking across tests without them).
bun test src/features/resource-settings/— 253 pass;packages/api— 15 pass;bun typecheck,bun checkclean.