Uh oh!
There was an error while loading. Please reload this page.
fix: show prompts a server ends with IAC GA - #38
Conversation
…t markers The Repository state section said TelnetNegotiationCore 2.7.0 while the pin in Directory.Packages.props said 2.8.1. A version in prose goes stale silently, so neither paragraph names one now: the pin is the single source of truth and the dependency notes say which release changed what. Records what the GA investigation established, since the same gap will be read for again: TelnetSession.OnPromptAsync is the only thing that flushes _pending, a default NVT ends its prompts with IAC GA and nothing else (RFC 854), RFC 858 is the only thing that makes a GA meaningless, and an unnegotiated IAC EOR is a NOP (RFC 885). Also notes the part that stays ours — a server sending no boundary marker at all still leaves a prompt in the buffer.
Only the EOR half of the prompt boundary was ever pinned, which is how a login screen that never appeared reached a release: a default NVT ends its prompts with IAC GA and nothing else, nothing flushed _pending for it, and no test noticed. Three tests, matching the three RFC rules: - IAC GA is a prompt when nothing suppressed it (RFC 854) - IAC GA is a NOP once SUPPRESS-GO-AHEAD is negotiated (RFC 858) - IAC EOR is a NOP while the option is not in effect (RFC 885) The negative pair assert an absence, which WaitAsync cannot express, so they wait for a later event they do expect and then read OutputWaiter.Snapshot() — deterministic rather than a sleep. The SGA test feeds negotiation and GA in one call: the interpreter reads bytes in order off one channel and awaits each transition, so the negotiation has completed by the time the GA is processed. Two of the three fail against the currently pinned 2.8.1, which is the point; they pass on the bump in the next commit.
Takes the prompt-marker fix (upstream PR #90): IAC GA is now reported as the prompt boundary RFC 854 makes it, so a server that negotiates neither EOR nor SUPPRESS-GO-AHEAD — most MU* servers — no longer leaves its prompt sitting in _pending with nothing to flush it. No client-side change is needed for it. AddDefaultMUDProtocols(onPrompt:) already wires one callback to both plugins, so the signal arrives with the version. Also crosses 2.9.0 (IsNegotiated beside the always-true IsEnabled), 2.9.1 (IAC GA and a bare IAC mid-negotiation get permitted transitions instead of hitting OnUnhandledTriggerAsync, which logged Critical on every prompt) and 2.10.0 (raw bytes beside each decoded MSSP value). All additive; nothing here had to move. 941 / 1818 / 83 / 42 / 37 across the five suites, all green.
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:27 minutes Limit details: You’ve used the included review currently available. Your 68 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
Comment |
What
A character-creation prompt on
tdome.nukefire.org:4000never appeared — the session read as a server that had stopped answering. The prompt had arrived and was sitting inTelnetSession._pendingwith nothing to flush it.OnPromptAsyncis the only thing that flushes that buffer, and it only ever fired forIAC EOR. NukeFire is a default NVT: it negotiates neither EOR nor SUPPRESS-GO-AHEAD and ends every prompt withIAC GA, which is what RFC 854 requires of it —TelnetNegotiationCore had no inbound handling for GA at 2.8.1 (it logged
Criticaland recovered throughTrigger.Erroron every prompt), and 2.10.0 accepted the byte but discarded it. Fixed upstream in PR #90 rather than worked around here, per the standing rule for this dependency.Changes
AddDefaultMUDProtocols(onPrompt: OnPromptAsync)already wires one callback to both plugins, so the signal arrives with the version. The bump also crosses 2.9.0 (IsNegotiated), 2.9.1 (StartNegotiationtransitions) and 2.10.0 (raw MSSP bytes), all additive.IAC GAis a prompt when nothing suppressed it (RFC 854)IAC GAis a NOP once SUPPRESS-GO-AHEAD is negotiated (RFC 858)IAC EORis a NOP while the option is not in effect (RFC 885)Directory.Packages.propsis the single source of truth. Adds release notes for 2.9.0–2.11.0 and records the prompt-marker rules, including the part that stays ours: a server sending no boundary marker at all still leaves a prompt in_pending, because nothing here flushes on idle.Verification
All five suites green against 2.11.0:
The two library-dependent tests were confirmed to fail against the previously pinned 2.8.1 before the bump — they are not passing vacuously.
Not in scope
The prompt reads
at right, Pemberton (<send>Y</send>/<send>N</send>)?. TheESC[1z/ESC[7zMXP line tags around it are discarded cleanly byAnsiParser, butContentFormatdefaults toAnsi, so the<send>tags themselves will now be visible as literal text. NukeFire never negotiated MXP — it sends the markup unsolicited. Deliberately left for separate work.🤖 Generated with Claude Code