mirror of
https://github.com/rustdesk/hbb_common.git
synced 2026-10-11 19:23:59 +00:00
rustdeskandClaude Opus 5
b4b0920460
- The on_data_channel guards called dc.close() from inside the handler, which webrtc-rs runs to completion BEFORE handle_open binds the SCTP stream. At that point close() only flips the ready state and returns, and handle_open sets it back to Open; with detached channels no read loop is spawned either. So a refused channel stayed open and undrained, and its queued bytes count against the association-wide receive window - about a megabyte written into an ignored channel stalls the one carrying the session, from an unauthenticated peer. Close from the channel's own on_open instead, where the stream exists. This is also what makes the ordered+reliable precondition an actual rejection rather than a log line. - A write that failed part-way through a fragment sequence called close_detached() and let the send permit drop, while the timeout path hands the permit to the teardown for exactly this reason: the close is in flight, state_notify is still Open, and callers wrap sends in allow_err! and keep going - so the next message could be written onto the orphaned prefix the failure left on the peer. send_bytes_inner now reports that it desynced and the caller, which holds the permit, does the teardown. - Drop the catch_unwind around Handle::spawn: release builds set panic = "abort", so it can never catch anything, and the comment claimed a mitigation that does not exist. The reachable case is having no runtime handle at all, which is now logged at debug rather than warn - Stream's Drop reaches this on every non-runtime thread. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ExUfAkYbq8UC9pQCiLy8TQ