Oracle: observe durable writes during sync-metadata read holds and abandonment
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ó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 8/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
- Lĩnh vực
- testing-qa
Hướng nghiên cứu
Start with the sync-metadata entry in docs/contributing/oracle-coverage.md, then the sync-metadata session oracle and its persisted and native receiving drivers. The work is to record durable transaction observations at the receipt boundary for read-hold and abandonment histories, independent of the production metadata classifier. Done means a parent RED trace, a repaired GREEN run, and a hostile mutant that the same comparison rejects, with exact commands and results recorded.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Coverage gap
The sync-metadata session coverage entry explicitly retains this observation obligation:
The read-hold and abandonment lanes retain source-facing comparisons but do not provide the peer lanes' direct durable transaction trace. A receiving witness must stage a wrong durable write followed by repair while a read hold buffers a commit, including abandonment, and reject it at the appropriate durable boundary.
This is a recorded test-instrument gap, not a newly demonstrated production defect. The text remains in the audited main source at c5ad6ad5a782ff04e9157bdef69399f2b5ba813b.
A final source-facing or repaired durable snapshot can miss an incorrect durable write that was later undone. The receiver needs an observation at the durable boundary where that write becomes observable.
Owner and work
Keep this under the existing sync-metadata session oracle and its persisted/native receiving drivers. Preserve the accepted laws that distinguish tab-local seed metadata, explicit durable metadata writes, unknown-author recovery and buffered-commit abandonment; do not redefine durable state to agree with a source read.
- Construct read-hold histories with a buffered commit, both eventual application and abandonment, and nearby controls.
- Record actual durable transaction observations at the appropriate receipt/boundary, independently of the production metadata classifier.
- Calibrate with a deliberately wrong durable write followed by repair. The same comparison must reject the transient violation even when final state agrees.
- Require measured generated reach and fixed/random replay parity.
- Preserve existing source-facing comparisons and budgets. Record exact commands, source bindings, results and receiving limits.
If this exposes a product failure, retain its trace and add parent RED / repaired GREEN / hostile-mutant evidence before claiming closure.
Related boundaries
#2272 tracks the broader real-coordinator/host receiving scope, including remaining transport and lifecycle cases. #2317 is a distinct source-facing controlled-notice failure. #2281 concerns row resurrection. This durable observation task does not assert a common cause or close any of those issues.
- 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)
- 176
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ể làm lại được @Claire-ovo đã nhận 8 ngày trước và không có pull request nào đang mở. Đ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 6 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
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 52/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
needs investigation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 60/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Makefile names visualizer gate targets that do not exist; the TS packages have no test runnerĐang mởarea:visualizer tech-debt
Độ khó 2/5 Dưới một giờ Mức phù hợp với người mới 66/100
jmbarzee/temporal-architect#292 ·
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 66/100
riverqueue/river#1576 ·
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 70/100
colbymchenry/codegraph#3228 ·
Maintainer thường phản hồi trong vòng 1 ngày