Ledger rebuild drops an in-flight settled marker when the in-flight scan fails
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
- Lĩnh vực
- backend
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- TypeScript
- Star
- 2.1k
- Fork
- 139
- Merge trung bình
- 5 giờ 5 phút
- Pull request đã merge (30 ngày)
- 923
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của coder/xum
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
🤖 fix: xum api exits 0 when a procedure returns success: falseCó thể đã có người làm @twotnguyen đã nhận 4 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
coder/xum#7733 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
excalidraw/excalidraw#12590 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Automattic/data-liberation-agent#1657 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
HGInsights/hgi-cli#23 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Impact: 3-Minor Scope: Core
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 74/100
sugarlabs/musicblocks-v4#1029 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày