You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Settings reset: an env-pinned key keeps its stored value beneath the pin, while the reset says the namespace is back on environment/default configuration #30664
Filing gate: ③ a maintainer ruling that names this card: #30385 ruling A (Ruling confirmed on the card, maintainer 「同意」 2026-11-05T21:34Z), item 2 — "resetNamespace and the built-in reset action are not touched here … a separate p3 card; it does not block this one." Read by the seat in the cited file on main. ⛔ Not a claim. Suggested grade: p3.
Dedupe: reset env-pinned stored value, resetNamespace locked-by-env. Nearest: #30385 (the clear of an env-pinned key, PR #30448). New.
What happens
SettingsService.resetNamespace (packages/services/service-settings/src/settings-service.ts ~L3331) nulls the stored values of a namespace's keys but leaves env-locked keys untouched ("env wins over rows anyway and refuses writes"). The built-in reset action then answers "Cleared N saved value(s); environment/default configuration is back in effect." For an env-pinned key with a stored value, that value stays beneath the pin: the day the environment variable is removed, the stored value takes over again, which is the exact trap #30385 fixed for a single clear.
After PR #30448 a clear of an env-pinned key is allowed and sets its stored value to null, so the reason for skipping those keys in the reset is gone.
Activity
objectstack-fleet commentedon Nov 5, 2026
triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U
Path: none
Triage: audit · p3 kept ·
domain:server· 2026-11-05T21:55Z⛔ Not a claim.
Generated by Claude Code