Split out of #1384 per review on #1390: #1390 fixes the session-vanishes-after-a-close-less-replay symptom, but two other symptoms recorded in #1384's original report are not verified fixed by that change and shouldn't ride along to auto-close under it.
1. Lingering DEVICE_IN_USE right after close
After closing a recording session, the immediate next replay can fail step 1 with DEVICE_IN_USE ("Device is already in use by session "default"") until a second explicit close --session default — a lingering claim/lease after teardown. Cf. the daemon-shutdown releaseSessionLease gap noted in the device-claim design.
2. Published-artifact rewrite under interleaved closes
One interleaved sequence of closes across a stale replay session + a PUBLISHED recording session left the published .ad rewritten with post-publication actions and two trailing close lines. PUBLISHED close-time saving is supposed to be disarmed (ADR 0016); the clean publish→get→close flow is hash-stable and verified, so this looks specific to the interleaved-stale-session case. Timeline available in the #1381 validation notes referenced from #1384.
Scope
Both need their own live-repro verification (real daemon over CLI, not the in-process provider harness) before a fix — the same category of client/IPC-layer gap #1384 turned out to be for the close-less case.
Split out of #1384 per review on #1390: #1390 fixes the session-vanishes-after-a-close-less-replay symptom, but two other symptoms recorded in #1384's original report are not verified fixed by that change and shouldn't ride along to auto-close under it.
1. Lingering
DEVICE_IN_USEright aftercloseAfter closing a recording session, the immediate next
replaycan fail step 1 withDEVICE_IN_USE("Device is already in use by session "default"") until a second explicitclose --session default— a lingering claim/lease after teardown. Cf. the daemon-shutdownreleaseSessionLeasegap noted in the device-claim design.2. Published-artifact rewrite under interleaved closes
One interleaved sequence of closes across a stale replay session + a PUBLISHED recording session left the published
.adrewritten with post-publication actions and two trailingcloselines. PUBLISHED close-time saving is supposed to be disarmed (ADR 0016); the clean publish→get→close flow is hash-stable and verified, so this looks specific to the interleaved-stale-session case. Timeline available in the #1381 validation notes referenced from #1384.Scope
Both need their own live-repro verification (real daemon over CLI, not the in-process provider harness) before a fix — the same category of client/IPC-layer gap #1384 turned out to be for the close-less case.