Collection lifecycle publication mismatch after cleanup and restart #2310

A generated Collection lifecycle publication history fails on clean main c351fc04d7f70dc59bf92ecbed310f899b9511cd and on PR #2307 head 1d619bb672b500099d05459927c10d21ba08fcb6. After cleanup and restart, settling a request emits a delete for a retained row. The independent publication model expects no batch at that checkpoint.

This mismatch is independently replayed on both commits. It is not yet diagnosed as a production defect versus an oracle model, driver, or checkpoint defect. PR #2307 changes Solid row materialization and framework conformance coverage; it does not change the failing publication owner or Core production code.

Executed evidence

• Failed Test (db-2) job
• Owner: packages/db/tests/collection-subscription-lifecycle-publication-oracle.property.test.ts
• Property: subscription-lifecycle.publication-history
• Seed: -1439698414
• Path: 1:22
• Checkpoint: assertPublications, line 763, after command index 5 (settle for demand b, current/newest, resolve).
• CI result: 14,444 tests passed, one assertion failed, no type errors.
• Both independent local replays reach the same assertion with the same shrunk history. The base replay used an archived clean base tree and the existing external test dependencies. No primary-checkout changes were used.

observed: [[{ type: 'delete', key: 'b', value: { id: 'b', value: 1 } }]]
expected: []

Shrunk history

[
  { "type": "source", "key": "b", "action": "upsert", "value": 1 },
  { "type": "request", "demand": "b" },
  { "type": "cleanup" },
  { "type": "settle", "demand": "a", "scope": "current", "age": "oldest", "outcome": "resolve" },
  { "type": "restart" },
  { "type": "settle", "demand": "b", "scope": "current", "age": "newest", "outcome": "resolve" },
  { "type": "abort", "demand": "a" },
  { "type": "settle", "demand": "a", "scope": "current", "age": "oldest", "outcome": "reject" },
  { "type": "release", "demand": "b" }
]

Replay

Run from the repository root at either recorded commit:

TANSTACK_DB_ORACLE_SEED=-1439698414 \
TANSTACK_DB_ORACLE_PATH=1:22 \
TANSTACK_DB_ORACLE_PROPERTY=subscription-lifecycle.publication-history \
pnpm --filter @tanstack/db exec vitest run \
  tests/collection-subscription-lifecycle-publication-oracle.property.test.ts \
  -t 'matches row publications for a random or replayed seed' \
  --maxWorkers=2 --coverage.enabled=false

Investigation and acceptance boundary

The owner compares exact callback batches and public rows after each command. Its opening contract and the shared lifecycle grammar govern cleanup, restart, and which acquisition attempts can authorize replacement publication. Identify the attempt selected at the failing settlement and why production deletes the retained row while the model leaves it visible. Establish the accepted retention/publication law before changing either implementation or model.

Preserve this history as a replay through the shared model, production driver, and comparison. Exercise neighboring cleanup/restart histories with and without preexisting rows, live demands, and current/obsolete settlements. A repair needs RED on unchanged production, GREEN after the repair, and a hostile mutant rejected at the intended publication checkpoint. A retry with a different random seed does not close this counterexample.

Related reports

• fix(db): publish a retired replay's rows instead of keeping stale ones #2121 (merged) changed retired truncate-replay publication and last-demand retirement in this owner. It does not record this cleanup/restart trace.
• fix(db): stop old notification holds from affecting restarted sync #1921 (merged) fixed notification deferrals across cleanup/restart. Its explicit deferral-handle history is different from this trace.
• Ordered live query publishes new rows during a failed marker replay #2294 concerns an ordered live query's failed marker replay, through a different owner.
• fix(db): preserve ordering invalidations during repair retirement #2302 repairs ordered-loader retirement and the separate Ordered loader retains earlier requests after a newer authoritative read succeeds #2296 replay-provenance mismatch. It does not modify this Collection publication owner.

The maintainer requested a separate issue while keeping #2307 focused on the adapter repair. No Core implementation, expectation, comparison, or oracle run budget has been changed or waived.