🤖 fix: config writes swallow save failures while the in-process snapshot keeps the edit
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
Direzione di ricerca
Start in src/node/config/index.ts by tracing saveConfigEffect, editConfig(), and readConfigOrDefault(). Review the config writers, including setUnrelatedWorkspaceConsent, and decide whether failed saves should surface or clear the snapshot. Done means failed writes cannot leave in-memory state diverging from config.json, and security-relevant callers fail closed.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
Config.saveConfigEffect (src/node/config/index.ts) logs write failures and swallows them (Effect.catch → log.error("Error saving config:")). As a result, editConfig() resolves even when nothing reached disk.
The config snapshot is cleared only after a successful write. readConfigOrDefault() caches the object it passes to the edit transform, so after a failed write every in-process reader sees the edited value, but config.json still holds the old one. The divergence becomes visible only after a restart, when the edit silently reverts.
This affects every config edit. One example: the unrelated-messaging consent toggle (setUnrelatedWorkspaceConsent), and the creation-time default grant added in #4440. Neither can detect the failure by re-reading, because the re-read returns the same cached object.
Suggested direction
Pick one:
- Surface write failures from
editConfig. - Drop the snapshot on a failed save so the next read reflects disk.
Then let security-relevant callers fail closed. This needs its own design pass because it touches every config writer.
Found during review of #4440 (Codex thread on grantCreationUnrelatedWorkspaceConsent); deferred there as pre-existing.
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
- Lingua principale
- TypeScript
- Stelle
- 2.1k
- Fork
- 142
- Merge medio
- 5h 26m
- PR unite (30g)
- 903
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di coder/xum
-
🤖 fix: two command-palette titles and old Windows rows still use a backslash-blind project nameForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
tech-debt
Difficoltà 2/5 Mezza giornata Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
tech-debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
chrisparsons83/flexspotff#215 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
vitest-dev/vitest#11633 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno