Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Ordered loader: recover failed ordered requests with a bounded repair instead of a full-source read

Đang mở
  • Có gì không ổn?
#2,165 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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ái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
data-engineering

Hướng nghiên cứu

The work centers on OrderedSourceLoader's fail, failRequest, finishOrderedPrefixRepair, abandonOrderedPrefixRepair, scheduleRepairRetry and the retry gate in loadMore. Before editing, read the ordered-source-loader, loader-state and pagination oracle tests, and the 'Ordered requests, continuation, and recovery' section of packages/db/src/query/live/ARCHITECTURE.md. Done means the bounded failure-recovery law is stated in those oracles and the pinned expectations, including the failing pagination-oracle tie-boundary and reject/abort lease cases, pass.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Problem

When an ordered request fails, the ordered loader recovers by reading the full source. That happens after a failed page, tie, or bounded-repair request, including a synchronous throw or a failed boundary read, and the automatic retries at 250 ms and 500 ms do the same. Full-source reads can be very expensive. Each plan that can continue from a provider prefix (!requiresFullSource) has a cheaper option: a bounded ordered-prefix repair from the start of the order. That repair sets its boundary from its own settled requests, so partial writes from the failed request cannot mislead it.

Rule (maintainer decision): avoid full-source reads whenever a bounded read is available.

PR #2154 applies this rule to an ordering invalidation that overlaps an in-flight page or tie request. It leaves failure recovery unchanged. These paths still read the full source:

  • recovery after a failed or canceled request;
  • an ordering invalidation that arrives before any request has settled.

What a first attempt showed

A prototype replaced requireFullSourceRepair() with a bounded repair on failure. It also retried the bounded repair in the automatic retries, and let a newer ordering invalidation retry once. Across five test files, 48 pinned expectations then failed. Some of them were real regressions:

  • pagination-oracle.property.test.ts, "recovers a failed tie boundary …": the window was [1, 4], expected [1, 2].
  • ordered-source-loader-oracle.test.ts, "keeps the 'boundary' acquisition lifecycle exact for reject/abort": after the tie request failed, the original page acquisition was not released.
  • pagination-oracle.property.test.ts, the pending-history campaigns and their captured-history controls: logical settlement did not match the model.

The failure path re-enters the bounded chain in states it was not built for, for example a failed request that overlaps a repair (the abandonOrderedPrefixRepair path).

Work

  1. In the ordered-source-loader, loader-state and pagination oracles, state the bounded failure-recovery law first:
    • recovery shapes;
    • the lease release of failed and superseded acquisitions;
    • the retry budget;
    • retry after a newer invalidation.
  2. Then change OrderedSourceLoader: fail, failRequest, finishOrderedPrefixRepair, abandonOrderedPrefixRepair, scheduleRepairRetry, and the retry gate in loadMore.
  3. Update "Ordered requests, continuation, and recovery" in packages/db/src/query/live/ARCHITECTURE.md.

Related: #2136, #2154. The coverage map backlog entry is "Bounded recovery after a failed ordered request".

Ngôn ngữ chính
TypeScript
Star
4k
Fork
277
Merge trung bình
17 giờ 40 phút
Pull request đã merge (30 ngày)
223

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của TanStack/db

Tất cả issue của TanStack/db

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.