Ledger rebuild drops an in-flight settled marker when the in-flight scan fails
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- backend
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.1k
- Forks
- 139
- Merge medio
- 4 h 38 min
- PR fusionados (30 d)
- 926
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de coder/xum
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
🤖 fix: xum api exits 0 when a procedure returns success: falsePosiblemente ocupada @twotnguyen la tomó hace 4 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
coder/xum#7733 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
ClickHouse/clickhouse-js#1130 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
bug claude Minor static-analysis
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
linagora/cozy-flagship-app#1359 ·
-
[Bug]: t3 connect status reports "Exposure: enabled" for publish-only links without a tunnelAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día