fix(dvc): drop data for a channel that is not open instead of failing - #2005
Open
meanaverage (meanaverage) wants to merge 2 commits into
Open
meanaverage (meanaverage) wants to merge 2 commits into
meanaverage (meanaverage) wants to merge 2 commits into
Conversation
meanaverage (meanaverage)
deployed
to
llm-providers
September 26, 2026 01:43 — with
GitHub Actions
Active
Contributor
|
Automated review will not run because this contributor is not yet eligible under the automation policy. Contributors become eligible after one qualifying IronRDP pull request is merged into |
meanaverage (meanaverage)
deployed
to
llm-providers
October 1, 2026 09:35 — with
GitHub Actions
Active
A server can send data on a dynamic channel before it sees the client decline that channel in its Create Response. GNOME Remote Desktop does this for AUDIO_PLAYBACK_DVC right after the Create Request, so a client without an audio channel failed `process` with "access to non existing DVC channel" and the session ended about a second after connecting. Such data has nowhere to go: log it and drop it.
As with a declined channel on the server side, this is not a fault, and a server may keep sending such data, so a warning per PDU would flood the log.
meanaverage (meanaverage)
force-pushed
the
fix/dvc-drop-data-for-unopened-channel
branch
from
October 1, 2026 18:22
067114b to
6407c22
Compare
meanaverage (meanaverage)
deployed
to
llm-providers
October 1, 2026 18:23 — with
GitHub Actions
Active
This branch was successfully deployed
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.
Problem
A server can send data on a dynamic channel before it has seen the client decline that channel in its Create Response. GNOME Remote Desktop (46.3, headless mode) does this for
AUDIO_PLAYBACK_DVC: a client without an audio channel answers the Create Request with a failure status, but the server's first data PDU is already on the wire.DrdynvcClient::process_datatreated that as an error (access to non existing DVC channel). The error ends the active session, so the connection drops about a second after it is established.Change
Log the data (
debug!, with the channel id, asDrdynvcServerdoes for a declined channel) and drop it. Data for open channels is routed exactly as before; the tunnel / Soft-Sync checks are untouched.Testing
dvc::client::data_for_a_channel_that_is_not_open_is_droppedinironrdp-testsuite-core. It fails onmasterwith the error above and passes with this change; the other DVC tests pass.cargo xtask check fmt,lints,locks,typospass.ironrdp-webconnects to GNOME Remote Desktop 46.3 (headless, Ubuntu 24.04) and stays connected. Without it, the session ends right after the audio channel is refused.Related: #1446
Prepared with AI assistance; I reviewed the change and ran the tests above.