Repository navigation
[REA-6846] Warn when a data channel refuses a frame - #229
Merged
douglaseel merged 2 commits intoOct 5, 2026
Merged
Conversation
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Oct 2, 2026
douglaseel
marked this pull request as ready for review
October 3, 2026 01:23
Dere-Wah
approved these changes
Oct 3, 2026
douglaseel
force-pushed
the
douglas/rea-6846-surface-refused-data-channel-sends
branch
2 times, most recently
from
October 5, 2026 14:50
1f8f017 to
224f688
Compare
douglaseel
force-pushed
the
douglas/rea-6846-reactor-runtime-enable-dc-chunking
branch
from
October 5, 2026 14:50
b55f0f0 to
20ccd70
Compare
douglaseel
force-pushed
the
douglas/rea-6846-surface-refused-data-channel-sends
branch
from
October 5, 2026 15:59
224f688 to
af4954c
Compare
Contributor
Author
Merge activity
|
douglaseel
changed the base branch from
douglas/rea-6846-reactor-runtime-enable-dc-chunking
to
graphite-base/229
October 5, 2026 16:44
Every send error was logged at debug level, since a send can race teardown and that race is expected. reactor-webrtc 0.19 adds two refusals that are not a race: a message larger than the client accepts, and one that would pass what a chunked channel may queue. The frame is lost while the channel stays open, so these are logged as warnings with the frame's size and channel. A send that races teardown stays at debug level. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Douglas Ferreira <douglaseel@gmail.com>
A model that oversends on every step logged a warning per frame, 30 a second or more. The first refusal of each kind on each channel of a connection is still a warning; repeats are logged at debug level. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Douglas Ferreira <douglaseel@gmail.com>
douglaseel
force-pushed
the
douglas/rea-6846-surface-refused-data-channel-sends
branch
from
October 5, 2026 16:44
af4954c to
2898bb7
Compare
douglaseel
deleted the
douglas/rea-6846-surface-refused-data-channel-sends
branch
October 5, 2026 16:46
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.

Why
The peer logs every data-channel send error at debug level, because a send can race teardown and that race is expected. reactor-webrtc 0.19 adds two refusals that aren't a race. One is a message larger than the client accepts. The other is a send that would pass what a chunked channel may queue. In both cases the frame is lost and the channel stays open, and an operator should be able to see that.
What Changed
DataChannelMessageTooLargeandDataChannelQueueFullare logged as warnings with the frame's size and channel. Every other send error stays at debug level. Nothing is raised, so callers ofsend_message/send_controland the model-author API see no change.Unit tests cover both refusals and the quiet teardown race.
🤖 Generated with Claude Code