[Bug]: Gateway session fixtures leave transcript reconciliation pending

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The Gateway reclamation fixture declares its transcript projections clean while leaving active rows unclassified, and its release helper does not wait for already-scheduled transcript reconciliation before disposing the fixture store.

Steps to reproduce

1. Use main at 162d0fcfcc91ef89416e5b80dd0ddeaf1d5bd13d.

2. In src/gateway/server.sessions.reclamation.test.ts, import listSessionsNeedingTranscriptIndexReconcile from the existing transcript-index owner and assert that it returns [] after seedTranscriptState commits. Leave the bulk active-row insert unchanged.

3. Run the existing 200,000-row case through its Gateway configuration:

   node scripts/run-vitest.mjs run --config test/vitest/vitest.gateway.config.ts src/gateway/server.sessions.reclamation.test.ts
   

The remote control run selected exactly one test and failed at this added readiness assertion. Its teardown used the existing directory-scoped reconciliation drain so the failed assertion could be cleaned up safely; the seed and pending-session selector were unchanged.

Expected behavior

The fixture's ordinary messages should have complete active-projection classification when its watermark says the projection is current. Setup should establish that condition before measuring deletion responsiveness. Once a fixture is deselected, release should settle its already-scheduled projection work before closing and removing its databases, while preserving work belonging to other fixtures.

Actual behavior

The active-row insert omits context_eligible, leaving NULL values for all three seeded session windows. The production selector treats those rows as pending even though needs_rebuild is zero and indexed_seq is current. The assertion returns the three session IDs below instead of an empty list.

The release helper drains admitted session work and deselects the store, then unregisters and closes databases. It does not join the separately scheduled transcript-reconciliation owner. A retained diagnostic run on main at 324208c38245d6e83813f3c1bc9641f076b055ec observed that owner reopening a writable fixture database after directory removal started. This is evidence of the lifetime gap; that run passed and did not reproduce the separate CI ENOTEMPTY failure.

OpenClaw version

Source main at 162d0fcfcc91ef89416e5b80dd0ddeaf1d5bd13d; readiness control retains the original seed and selector.

Operating system

Linux, Node.js 24.19.0.

Install method

Source checkout with the existing frozen pnpm lockfile and native Gateway Vitest configuration.

Model

Not applicable; the test uses synthetic session data.

Provider / routing chain

Not applicable; no external model or channel service is invoked.

Logs

AssertionError: expected [ 'phase3-reclamation-e2e', …(2) ] to deeply equal []

Received:
[
  "phase3-reclamation-e2e",
  "phase3-reclamation-e2e-history",
  "phase3-reclamation-unrelated"
]

Test Files  1 failed (1)
     Tests  1 failed (1)

The command exited 1 after 44.615 seconds. The failure was at the new readiness assertion, before deletion measurement.

Screenshots, recordings, and evidence

The source boundaries at the tested main revision are the bulk fixture seed, the pending projection selector, and the fixture release helper. The existing reconciliation owner already provides a directory-scoped drain that includes later matching owners.

Impact and severity

This affects developers running Gateway session tests: fixture setup schedules unintended rebuilding, and teardown can overlap write-capable work. The readiness mismatch was demonstrated in one focused control run; this report does not claim a measured frequency for intermittent CI failures or an end-user data-loss incident.

Additional information

This is separate from #140944, which concerns the fixed heartbeat threshold, and #112423, which concerns production reclamation resource use. A fixture repair should preserve the 200,000-row workload, all deletion/history/archive/isolation assertions, and the existing responsiveness measurement. It does not require production scheduler, schema, or global cancellation changes.