feat(server): add diagnostic logging for EGFX flow control and dispatch timing - #1834
Open
Greg Lamberson (glamberson) wants to merge 1 commit into
Open
Conversation
Greg Lamberson (glamberson)
deployed
to
llm-providers
August 29, 2026 02:07 — with
GitHub Actions
Active
…ispatch timing The EGFX flow-control loop (backpressure, ack_suspended, FrameAcknowledge) and the server's per-PDU dispatch loop were both effectively invisible at default log levels. FrameAcknowledge, the single most important signal in the flow-control loop, was only logged at TRACE. Backpressure/ack_suspended transitions were not logged at all, and dispatch_pdu had no way to distinguish lock contention from a slow handler or runtime stall. - FrameTracker now edge-triggers a debug log when backpressure or ack_suspended change state, instead of logging every call (which would flood at 30+/sec) or nothing at all. - FrameAcknowledge is now logged at DEBUG with latency, queue_depth, and in-flight count. An ack for an unknown frame_id (protocol violation or stale ack per MS-RDPEGFX 2.2.4.3) is now a warning instead of silent. - drain_output (ZGFX compression) now tracks per-batch compress time and ratio, logging at INFO when a batch exceeds a 10ms budget and DEBUG otherwise, since it runs under both the state lock and the writer lock and can block inbound PDU processing. - Incoming EGFX DVC PDUs are logged at DEBUG with their kind, so the client-to-server side of the channel is visible without enabling TRACE. - dispatch_pdu and dispatch_events now separately time lock-acquisition wait and handler dispatch, warning when either exceeds 50ms so the two causes (lock contention vs. handler/runtime stall) can be told apart instead of both surfacing as one generic slow-dispatch symptom.
Greg Lamberson (glamberson)
force-pushed
the
feat/server-egfx-dispatch-diagnostics
branch
from
August 29, 2026 13:50
b7ed25a to
b0c44ac
Compare
Greg Lamberson (glamberson)
deployed
to
llm-providers
August 29, 2026 13:51 — with
GitHub Actions
Active
Greg Lamberson (glamberson)
deployed
to
llm-providers
August 29, 2026 14:01 — with
GitHub Actions
Active
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
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.
I ran into a case where I needed to debug slow frame acknowledgement and dispatch stalls in ironrdp-server and ironrdp-egfx, and found the relevant signals were either missing or buried at TRACE level where nobody enables them in normal operation. This PR adds targeted diagnostic logging without changing any behavior.
No public API changes, no behavioral changes, logging only.
Note on CI: the workspace-wide test compile is currently broken on master independent of this PR, ironrdp-daemon's consume_output() call site passes a raw Receiver where OutputEventReceiver is expected. I confirmed this reproduces on a clean, unmodified checkout of master. This PR only touches ironrdp-server and ironrdp-egfx.