Skip to content

Fix #5453: log unknown client messages - #5488

Open
MsfPablo wants to merge 2 commits into
tmux:masterfrom
MsfPablo:fix-5453
Open

Fix #5453: log unknown client messages#5488
MsfPablo wants to merge 2 commits into
tmux:masterfrom
MsfPablo:fix-5453

Conversation

@MsfPablo

Copy link
Copy Markdown

Fixes #5453

When the client receives an unknown message type, it currently silently
waits. This adds a debug log so unknown messages are visible at debug
level while keeping the client alive for forward compatibility (as
requested by the maintainer @nicm).

Both dispatch switch statements (client_dispatch_wait and
client_dispatch_attached) now have a default case calling log_debug
with the unknown message type.

🤖 Generated with Claude Code

Pablo Garcia and others added 2 commits August 7, 2026 16:13
cmd_source_file_exec() bumps either the static cmd_source_file_depth (no
client) or c->source_file_depth, but the completion callback re-derived
the client from a different queue item and so could decrement the other
counter.

The mismatch is easy to hit: file_create_with_client() clears the client
when it is attached, so for a hook-driven source-file the increment lands
on c->source_file_depth while the decrement lands on the static counter.
c->source_file_depth then grows by one per hook invocation until every
source-file from that client fails with "too many nested files", and the
static counter underflows past zero.

Remember the client in struct cmd_source_file_data and pass it to the
callback so the decrement always targets the counter that was
incremented, taking a reference for the duration.
Instead of silently waiting, log unknown message types at debug level
so future protocol additions do not hang the client.

Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Not Started

Development

Successfully merging this pull request may close these issues.

Client hangs forever with no output when the server sends an unrecognised message type

1 participant