Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Ordered live query publishes new rows during a failed marker replay

Ouverte
  • Quelque chose ne va pas ?
#2,294 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
typescript
Domaine
backend, testing-qa

Piste de recherche

Start with packages/db/tests/query/load-subset-replay-refinement-oracle.test.ts and replay the recorded seed and path using the provided Vitest command. Compare the production behavior with the shared model/driver comparison and the deferred trace cited in the issue, checking whether the barrier remains held or fails at the recorded cut. Done means identifying whether the counterexample exposes a production defect or a model/observation-cut defect, preserving both traces, and adding the requested neighboring cases before any production repair.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

A generated replay-retention history failed on main at 82c5f999b32c9db827dd74e3f172604dfda28013 while preparing the first RC. The query published row 3 while its retained complete result was still empty.

CI evidence

  • Failed Release job
  • Owner: load-subset-replay-refinement-oracle.test.ts
  • Property: replay.ordered-failed-replay, random campaign
  • Seed: -2135028650
  • Path: 249:0:1:1:1:1:1:5:6
  • Checkpoint: retained publication once loading is quiet, checkRetention line 1444
  • Result: 9,771 tests passed, one assertion failed, no type errors. This was not a timeout or a missing-reach failure.
  • Host: GitHub Actions Ubuntu, Node 24.8.0, Vitest 4.1.12, fast-check 3.23.2.
expected [ { id: 3, rank: 30, … } ] to deeply equal []

Shrunk history

[
  { "type": "hold" },
  { "type": "truncateMarkers" },
  { "type": "settle", "ok": true, "keepHolding": true, "newest": false },
  { "type": "settle", "ok": true, "keepHolding": true, "newest": false },
  { "type": "settle", "ok": false, "newest": true, "keepHolding": true },
  { "type": "mark", "id": 3, "on": false }
]

{
  "direction": "asc",
  "offset": 1,
  "limit": 1,
  "ties": false,
  "peer": false,
  "joined": "none",
  "markerMode": "on-demand",
  "includes": true,
  "abortedMarkerLoads": "resolve",
  "historyDuringPreload": false
}

Replay from packages/db on the recorded commit with its dependencies installed:

TANSTACK_DB_ORACLE_PROPERTY=replay.ordered-failed-replay \
TANSTACK_DB_ORACLE_SEED=-2135028650 \
TANSTACK_DB_ORACLE_PATH=249:0:1:1:1:1:1:5:6 \
pnpm exec vitest run \
  --coverage.enabled=false --typecheck.enabled=false \
  tests/query/load-subset-replay-refinement-oracle.test.ts \
  -t 'keeps the last publication through a failed replay'

The seed, path, history and mismatch above are from the executed CI run. This exact trace has not been independently replayed on the older main baseline, so it does not yet establish whether the current counterexample is identical to the earlier deferred defect.

Expected behavior and follow-up

Live-query architecture, law 9 and “Replay participants and failure” requires a failed or still-held replay to retain the last complete publication. Identify which acquisition still holds or fails the barrier at the recorded cut, and discriminate a production publication defect from any model or observation-cut defect before changing either one.

This is the same owner and retention comparison as the shared-source replay with late include demand already deferred from the RC. That record preserves another baseline failure at seed 521312968, path 255:3:3:8:11:9.

Preserve both traces in the shared model/driver comparison, extend generated reach for late include demand and held replacements, and include success/abort/failure neighbors before a production repair. A later successful random campaign does not close this defect.

The maintainer requested retaining this counterexample in a follow-up issue and restarting the release workflow. No test, comparison or run budget was weakened. #2290 addresses a separate source-health reach problem; it is not evidence that this retention failure is fixed. Related release preparation: #2171 and #2217.

Langage dominant
TypeScript
Étoiles
4k
Forks
277
Merge moyen
1 j 6 h
PR mergées (30 j)
199

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de TanStack/db

Toutes les issues de TanStack/db

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.