Oracle: observe durable writes during sync-metadata read holds and abandonment

オープン
  • 何か問題がありますか？
#2,341 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
8/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
testing-qa

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
4k
フォーク
277
平均マージ
1日 7時間
マージ済み PR（30日）
170

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

TanStack/db のほかの issue

TanStack/db の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。