Ledger rebuild drops an in-flight settled marker when the in-flight scan fails
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
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- backend
Direzione di ricerca
Start in src/node/services/sessionUsageService.ts, at markInFlightFilesCountedByHistory, where (await this.readInFlightEntries(workspaceId)) ?? [] turns a failed listing into an empty list, and at rebuildFromMessagesInternal, which calls it. Compare with repairLedgerFromHistory, which already aborts on a failed first scan. Done means a failed scan aborts the write in every rebuild caller, the checked entries are reused instead of scanned twice, and a fault-injection test covers a transient listing failure with an orphaned in-flight file.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
A ledger rebuild from history can write the ledger without an in-flight file's settled marker when the in-flight scan fails. A later fold can then count that file's usage twice.
Where
src/node/services/sessionUsageService.ts, markInFlightFilesCountedByHistory: (await this.readInFlightEntries(workspaceId)) ?? [] treats a failed listing as "no files". rebuildFromMessagesInternal calls it on every rebuild.
After #7868, the repair path (repairLedgerFromHistory) scans once and refuses to write when that scan fails, but the rebuild then scans a second time, and only the first scan is checked. Codex raised this on #7868 (thread PRRT_kwDOPxxmWM6yfjDQ).
Trigger
All of these at once: an orphaned in-flight file exists, its assistant message is already in history, and listing or reading the in-flight folder fails transiently during the rebuild's scan.
Fix
Pass the checked entries from the first scan into rebuildFromMessagesInternal and markInFlightFilesCountedByHistory, and make a failed scan abort the write in the other rebuild callers. Add a fault-injection test.
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
- Lingua principale
- TypeScript
- Stelle
- 2.1k
- Fork
- 139
- Merge medio
- 4h 38m
- PR unite (30g)
- 926
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
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
🤖 fix: xum api exits 0 when a procedure returns success: falseForse già presa @twotnguyen l’ha presa 4 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
ClickHouse/clickhouse-js#1130 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
bug claude Minor static-analysis
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
linagora/cozy-flagship-app#1359 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno