Ordered replay oracle: pending window move rejects with later include-load error

Offen
#2,315 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
node.js, typescript

Rechercherichtung

Start with the replay.ordered-failed-replay property in packages/db/tests/query/load-subset-replay-refinement-oracle.test.ts and the recovery rules in packages/db/src/query/live/ARCHITECTURE.md. Run the supplied guarded replay from packages/db to confirm the error-identity failure, then trace how the model, driver, and comparison determine which failure decides the move. Done means the existing oracle passes the trace and nearby histories without weakening the assertion.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug
  • I've validated the bug against the latest version of DB packages

Describe the bug

The generated ordered-replay oracle finds a reproducible error-identity mismatch for a pending window move. After an include source's truncate replay fails, a later synchronous marker-load failure becomes the window move's rejection instead of the replay's earliest failure that still decides it.

Observed assertion:

replay error identity: move 1 rejected with "marker load threw", not its replay's earliest failure that still decides it

This is an assertion failure at the oracle comparison, not a timeout or setup failure. The same minimized history and assertion reproduce locally with PR #2309's production code and with the production changes reverted to its merge-base. The production/model cause has not been isolated.

To reproduce

Known failing source revision: a5c4986a14dc6c6a90ed9b194457edefba9a4a48 (the final head of merged PR #2309).

With dependencies installed, run from packages/db:

TANSTACK_DB_ORACLE_PROPERTY=replay.ordered-failed-replay TANSTACK_DB_ORACLE_SEED=963116110 TANSTACK_DB_ORACLE_PATH=318:2:1:6:5:7:6:6:6:6:9 node --import tsx tests/oracle-replay.ts   tests/query/load-subset-replay-refinement-oracle.test.ts   --maxWorkers=2 --coverage.enabled=false

The guarded replay records the requested property, seed and path, executes one failing history, and exits nonzero with the assertion above. The failing test is keeps the last publication through a failed replay (replay campaign).

The minimized generated input is:

[
  [
    { "type": "hold" },
    { "type": "truncateMarkers" },
    { "type": "window", "offset": 0, "limit": 1 },
    { "type": "settle", "ok": false, "newest": true },
    { "type": "markerThrows" },
    { "type": "move", "id": 4, "rank": 1 }
  ],
  {
    "direction": "desc",
    "offset": 0,
    "limit": 2,
    "ties": false,
    "peer": false,
    "joined": "none",
    "markerMode": "on-demand",
    "includes": true,
    "abortedMarkerLoads": "resolve",
    "historyDuringPreload": false
  }
]

These are inputs to the existing oracle driver, including its initial setup and final settlement. They are not a standalone public-API reproduction.

Expected behavior

A window operation waiting on a replay that fails must reject with that replay's own error: its earliest failure that still decides it. The architecture states this rule in Ordered requests, continuation, and recovery.

The final settlement checkpoint should pass the error-identity comparison without relaxing the oracle. Investigation should determine whether production loses the relevant failure or the oracle incorrectly attributes which replay/failure decides the move.

Evidence and scope

  • Failing CI job: the random campaign failed after 319 histories and ten shrink steps. The shard reported one failure and 10,080 passing tests.
  • Primary oracle and comparison: property replay.ordered-failed-replay.
  • Local guarded replay at a5c4986a14dc6c6a90ed9b194457edefba9a4a48: same minimized input, same assertion.
  • Baseline control: temporarily restored all eleven existing production files changed by #2309 to c351fc04d7f70dc59bf92ecbed310f899b9511cd, then ran the same guarded replay. It failed with the same input and assertion. The added unary-construction helper remained present but was unused by the restored operators. Every PR source file was restored afterward.
  • packages/db/src and this oracle file were unchanged between that merge-base and the PR head. This control establishes that #2309 did not introduce this failure. It was not a separate clean checkout of the entire baseline repository.
  • PR #2309 merged as 0531c50ad419a1b51ad3e27e3632e70be3c6bdb3 with this baseline failure explicitly accepted and recorded. The merged commit and current published package releases have not been independently replayed for this report.

Environment

  • CI: GitHub Actions, Ubuntu runner.
  • Local reproduction: macOS arm64, Node.js v24.19.0, pnpm 11.1.0.
  • Vitest 4.1.12, fast-check 3.23.2.

Repair validation

Preserve this trace as a replay through the shared model, driver and comparison. Use the existing primary oracle to check nearby histories with both rejected and synchronously throwing include loads, changing which failed demand remains relevant before the move settles. Establish the responsible production or model rule before changing expectations, then demonstrate RED/GREEN and a hostile mutant at the error-identity checkpoint.

Vorherrschende Sprache
TypeScript
Sterne
4k
Forks
277
Ø Merge
1 T. 9 Std.
Gemergte PRs (30 T.)
162

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus TanStack/db

Alle Issues in TanStack/db

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.