Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Ordered live query publishes new rows during a failed marker replay

Aberta
  • Algo errado?
#2,294 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
backend, testing-qa

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
4k
Forks
277
Merge médio
1d 4h
PRs com merge (30d)
212

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de TanStack/db

Todas as issues de TanStack/db

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.