fix(seats): the teardown warning overstated the stall - #51
Merged
Conversation
The warning shipped in #50 said the standalone Apollo's stream "will stall for about a second". Verified on the reference host today and that is wrong in the direction that matters -- it makes operators expect something worse than happens. Measured with a client genuinely streaming the console Apollo while a seat was provisioned and torn down: 08:49:23.503 warning fired 08:49:24.661 Apollo: Creating encoder <- 1.2s AFTER the warning 08:49:25.099 Session 8 logged off 08:49:31.996 Apollo: Creating encoder <- 7s after teardown, unexplained The rebuild took 266 ms, against the 690 ms measured on 2026-09-04, and the person streaming DID NOT NOTICE IT AT ALL. So: "hitch for a few hundred milliseconds", not "stall for about a second". CLAUDE.md carries the same correction, with both measurements and the caveat that one user's perception on one LAN does not prove it is always imperceptible. Two other things this run settled, both recorded on #23 rather than here: - Provisioning did NOT cause a rebuild. The session was created at 08:49:09.933 with no encoder activity near it, which supports the original observation in the issue rather than contradicting it. An earlier reading of mine that claimed otherwise was wrong -- corrected by correlating timestamps instead of eyeballing a log tail. - The warning fires BEFORE the stall, by 1.2s, which was the whole point of placing it ahead of the lifecycle gate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQvL62WkT8xDWXqyjFCGDw
Merged
vibesoftwarecoder
added a commit
that referenced
this pull request
Sep 13, 2026
version.txt 0.6.4 -> 0.6.5, plus the notes the release workflow reads. No code changes -- four merged commits ship: #49 (a streaming seat reported Ready), #50 (a streaming standalone Apollo reported idle), #51 (that warning overstated the stall), #52 (the audit gate failed on a registry outage). ⭐ Three of the four are runtime-verified on the reference host rather than only CI-green: #49 Ready -> Streaming in 6s on connect, back in 3s on disconnect #50 streaming signal correct in BOTH directions, including a live stream the old serverinfo check reported as idle #51 266 ms measured, and the person streaming did not notice it⚠️ And master CI was RED before this. 45f46b0 failed on a 400 from registry.npmjs.org, not on our code -- the same commit had passed its own PR 45 minutes earlier and passed locally afterwards. #52 fixed the gate; the master push on b5feaac is green across all three jobs, checked before cutting rather than assumed. That is worth recording: "the tests pass" is not "master is green", and I reported the first while implying the second. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQvL62WkT8xDWXqyjFCGDw
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The warning shipped in #50 said the standalone Apollo's stream "will stall for about a second". Verified on the reference host today, and that is wrong in the direction that matters — it makes operators expect something worse than what happens.
Measured with a client genuinely streaming
The rebuild took 266 ms, against the 690 ms measured on 2026-09-04 — and the person streaming did not notice it at all.
So: "hitch for a few hundred milliseconds", not "stall for about a second".
CLAUDE.mdcarries the same correction, with both measurements and the caveat that one user's perception on one LAN does not prove it is always imperceptible.What else this run settled
The warning fires before the stall, by 1.2 seconds. That was the entire reason for placing it ahead of the lifecycle gate, and it is now observed rather than assumed.
Provisioning did not cause a rebuild. The RDP session was created at
08:49:09.933with no encoder activity anywhere near it, which supports the original observation in #23 rather than contradicting it.One thing remains unexplained: a second encoder rebuild seven seconds after teardown completed, with no MultiSeat activity near it. Possibly the client, possibly a delayed topology settle. Recorded rather than guessed at.
546 tests passing.
🤖 Generated with Claude Code
https://claude.ai/code/session_01SQvL62WkT8xDWXqyjFCGDw