Ordered loader retains earlier requests after a newer authoritative read succeeds
Maintainer thường phản hồi trong vòng 1 ngà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
Hướng nghiên cứu
Start with packages/db/tests/query/ordered-source-loader-state-oracle.test.ts, especially checkAuthorityCase near line 1632, and replay the recorded seed and path on the specified commit. Compare production request retirement with the oracle’s model and observation checkpoint, then exercise the nearby synchronous repair, release-triggered truncate, and joined-work histories. Done means the original failure is reproduced, a repair passes the shared comparisons, a hostile mutant fails, and a real Collection or provider witness supports any public resource claim.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The Release workflow for the first RC failed the ordered-loader request-authority oracle on merged release commit 71bf598a3d13d37db28ac112431fd8be790957fe (#2217).
Executed CI evidence
- Failed Test (db-2) job
- Owner:
packages/db/tests/query/ordered-source-loader-state-oracle.test.ts - Test:
holds, retires, and recovers requests under generated settlement orders (random campaign) - Property:
ordered-loader.request-authority - Seed:
-845274422 - Path:
2109:1:3:6:4:8:10:13:15 - Failed after 2,110 generated tests, shrunk eight times.
- Assertion checkpoint:
checkAuthorityCase, line 1632, after the history drain and any explicit retry.
no leak: requests [3,4] are still held after authoritative request 5 succeeded
{"indexed":false,"limit":1,"settledFirst":true,"releaseFault":false,"syncRepair":true,"requiresFullSource":false,"joined":true,"snapshotRows":1,"needsMore":true,"retryTimer":false,"releaseTruncates":true,"offset":0,"releaseReenters":false,"releaseDisposes":false,"history":[{"type":"settle","pick":0,"ok":true},{"type":"settle","pick":0,"ok":true},{"type":"report","react":false},{"type":"move","delta":-1},{"type":"joinedBusy"},{"type":"settleNewest"}]}
Accepted law and limits of this report
The owner's “No leak” law states that once loading is quiet and no failure blocks it, the loader holds nothing issued before its last successful authoritative read. Retained demands can be read again on later refetches. The oracle uses the real loader with a controlled subscription; this mismatch establishes a failing request-ledger comparison, not incorrect public query rows or a measured production resource leak. Diagnose production retirement versus the oracle's model, replay ownership and observation checkpoint before changing either one.
This exact trace has not yet been replayed independently. The observed assertion is from the executed CI run; it is not a timeout or a reach failure.
Replay
Run from packages/db on the recorded commit:
TANSTACK_DB_ORACLE_PROPERTY=ordered-loader.request-authority \
TANSTACK_DB_ORACLE_SEED=-845274422 \
TANSTACK_DB_ORACLE_PATH=2109:1:3:6:4:8:10:13:15 \
pnpm exec vitest run --coverage.enabled=false --typecheck.enabled=false \
tests/query/ordered-source-loader-state-oracle.test.ts -t 'random campaign'
Keep this history in the shared comparison and exercise nearby synchronous repair, release-triggered truncate and joined-work histories before a production repair. Show RED on the original code, GREEN after repair and a hostile mutant that fails. A real Collection/provider receiving witness is needed before claiming the public resource consequence is closed.
Related loader retirement investigations: #2223 (failed request across cursor reset) and #2191 (request authority/retirement). This trace has only successful explicit settlements; identity with either earlier report is not established. It is separate from the publication-retention report #2294 and multi-tab Electric report #2281.
The maintainer explicitly approved recording this counterexample as a follow-up and retrying the first RC release while leaving the defect open. No test, comparison or run budget has been weakened. A passing retry does not close this issue.
- Ngôn ngữ chính
- TypeScript
- Star
- 4k
- Fork
- 277
- Merge trung bình
- 1 ngày 7 giờ
- Pull request đã merge (30 ngày)
- 191
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọ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 TanStack/db
-
`Collection.currentStateAsChanges` JSDoc examples don’t match `CurrentStateAsChangesOptions`Đang mở
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
OfflineExecutor.dispose() never settles pendingTransactionPromisesCó thể đã có người làm @Claire-ovo đã nhận 5 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
TanStack/db#2254 · 1 bình luận ·
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 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Two @tanstack/db tests time out under CPU load because a cold module import counts against the 5 s default timeoutCó thể đã có người làm @jp-knj đã nhận 3 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Disabled useLiveQuery fails SSR hydration with error 253Có thể đã có người làm @Jaime02 đã nhận hôm nay. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 42/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
guards: accept readonly arrays (and other array-likes) in isEmpty / hasElements / safeLengthĐang mởenhancement tech debt
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/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
danielmiessler/LifeOS#2533 ·
Maintainer thường phản hồi trong vòng 9 ngày
-
auto:producer auto:uiux
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
fritzprix/libr-agent#2447 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug low priority
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/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 72/100