Skip to content

Read settings from one storage snapshot - #1600

Merged
KillariDev merged 5 commits into
mainfrom
fix/atomic-settings-snapshot
Sep 21, 2026
Merged

KillariDev merged 5 commits into
mainfrom
fix/atomic-settings-snapshot

Conversation

@KillariDev

Copy link
Copy Markdown
Contributor

Summary

  • acquire every getSettings() field in one browser.storage.local.get() call
  • validate and recover each field independently from that shared snapshot
  • retain missing-value defaults, explicit address clears, and website icon sanitization
  • add a regression proving later storage state cannot be mixed into the returned settings

Why this matters

Settings writers can update simulation mode, address, and RPC together in one storage call. Previously, getSettings() performed two reads per field across seven parallel getters, so a concurrent mode change or import could return a torn combination of old and new security settings. That mixed state feeds provider routing, access decisions, and simulation behavior.

Validation

  • focused settings/storage suites (33 passed)
  • bun run test (1,260 passed)
  • bun run setup-chrome
  • bun run typecheck
  • bun run lint
  • independent reviewer: 95/100, no findings

@KillariDev

Copy link
Copy Markdown
Contributor Author

/review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

CI Agent Review

No security, runtime-correctness, or architectural-regression issues were reported by any agent. The refactor (single atomic storage snapshot in getSettings()) is behavior-preserving: defaults, presence-aware parsing for the address keys, corruption handling, and websiteAccess sanitization are all unchanged. The one minor concern raised is a style/cohesion observation about the new import edge from settings.ts to methodHandlers.js.

import { mergeStoredWebsiteMetadata, sanitizeWebsiteAccess } from '../utils/websiteIcons.js'
import type { SigningAddressPreference, SigningAddressPreferences } from '../types/signerTypes.js'
import { hasOwnKey } from '../utils/methodHandlers.js'

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Minor cohesion concern (low severity, non-blocking): this import pulls the generic object-own-key guard hasOwnKey from methodHandlers.js, a module whose purpose is RPC-method dispatch. Importing a general-purpose utility from that module into the settings/storage domain extends coupling across module boundaries and is a cohesion smell. This is noted as pre-existing utility misplacement rather than a regression introduced here, but a generic utils module (e.g. utils/typescript.ts) would be a cleaner home for hasOwnKey.

@KillariDev

Copy link
Copy Markdown
Contributor Author

/review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

CI Agent Review

No security or correctness issues found. All four agents confirmed the atomic-batched settings read preserves existing parsing, sanitization, and corruption-repair behavior without introducing new risks.

@KillariDev

Copy link
Copy Markdown
Contributor Author

/review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

CI Agent Review

No issues found.

@KillariDev
KillariDev merged commit 733f8d5 into main Sep 21, 2026
1 check passed
@KillariDev
KillariDev deleted the fix/atomic-settings-snapshot branch September 21, 2026 07:16
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.

2 participants