fix: bound in-game chat sends and stop refetching map dimensions

[HandyS11]

Two defects found while diagnosing a silent #events outage on a live bot. Neither is the cause of that outage (the paired server simply publishes no world markers over Rust+, verified at the wire/protobuf/mapping/model layers) — but both are real, and the first is the same failure class as #81.

1. An unbounded in-game chat send could kill a relay loop permanently

SendTeamMessageAsync / SendClanMessageAsync were the only 2 of 19 IRustServerConnection calls without a TimeSpan timeout. RustPlusApi resolves a send when the server answers it, so a response the server never delivers left the task pending forever.

EventRelay, PlayerEventRelay and AlarmStateRelay all await the in-game broadcast inline, before posting to Discord. One unanswered send therefore parked the consumer loop for good:

• nothing throws, so EventBusConsumption's per-event onHandlerFailure never fires;
• nothing throws, so the outer LogRelayLoopFaulted catch never fires;
• the unbounded channel silently accumulates every later event.

Net effect: #events, #playerevents and alarms go dead with zero log output, while the connection, heartbeat and map repaint all stay healthy — indistinguishable from "nothing is happening in game".

Both calls now take a timeout and guard it with timeoutCts + .WaitAsync, matching every sibling in RustPlusSocketSource. ConnectionSupervisor.SendAsync additionally enforces the ceiling itself, so the guarantee holds for any IRustServerConnection implementation rather than depending on one honouring the timeout it is handed. Its catch is now when (cancellationToken.IsCancellationRequested), so a request timeout degrades to ChatSendResult.Failed instead of propagating as cancellation — the trap already documented for the connect path.

2. Reading map dimensions downloaded the entire map

IRustServerQuery.GetMapDimensionsAsync went straight to the socket, where it is GetMap — a full map JPEG download — to read Width/Height. Its callers are ServerTeamMessageRenderer and MapComposer, which re-render several times a minute, and the connected window had already resolved the same values into DimensionsHolder via the marker poll.

Measured on the running bot with ss -tnpi: ~700 KB bursts every ~9s, ~1.1 GB over five hours. BaseMapCache already holds the image until disconnect, so this was the only repeated caller of the full-map endpoint.

LiveSocket now carries the window's DimensionsHolder and the query serves from it, fetching once only if a reader beats the marker poll's first resolution. Dimensions are fixed for a wipe, and the window is torn down and re-resolved on reconnect — exactly when they can change.

Testing

Two regression tests, both watched failing before the fix:

Test	Failure before fix
SendAsync_reports_failure_when_the_socket_never_answers_the_send	TimeoutException after 5s (the real hang)
GetMapDimensions_ServesRepeatReadsFromTheConnectedWindow_WithoutRefetching	Expected: 1, Actual: 6 — five redundant full map downloads

Full suite: 1401 passed, 1 skipped (1399 before + the 2 new). pre-push ReSharper formatting check passes.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The changes are targeted, reduce operational risk (hangs/bandwidth), and are backed by focused regression tests; only minor documentation wording nits were found.

Pull request overview

This PR addresses two reliability/performance defects in the Rust+ connection layer: (1) bounding in-game chat sends so relay loops can’t hang indefinitely on a missing server response, and (2) avoiding repeated full map image downloads when only map dimensions are needed by serving dimensions from the connected window cache.

Changes:

• Added request timeouts for team/clan chat sends and enforced them at the supervisor level to prevent relay-loop deadlocks.
• Cached map dimensions per connected window (and published on first fetch) to stop refetching dimensions via full map downloads.
• Added regression tests covering both the bounded-send behavior and the “no refetch” dimensions behavior.

File summaries

File	Description
tests/RustPlusBot.Features.Connections.Tests/TeamChatSenderTests.cs	Adds regression test ensuring a non-responding send is bounded and returns Failed.
tests/RustPlusBot.Features.Connections.Tests/MapImageQueryTests.cs	Adds regression test ensuring repeated dimension reads don’t refetch from the socket.
tests/RustPlusBot.Features.Connections.Tests/Fakes/FakeRustSocketSource.cs	Extends fake connection to simulate hung sends and count map-dimensions calls.
src/RustPlusBot.Features.Connections/Supervisor/ConnectionSupervisor.cs	Enforces bounded chat sends and serves map dimensions from a per-window cache.
src/RustPlusBot.Features.Connections/Listening/RustPlusSocketSource.cs	Updates send methods to accept a timeout and bound the underlying RustPlusApi call.
src/RustPlusBot.Features.Connections/Listening/IRustServerConnection.cs	Updates the connection interface to require timeouts for chat sends.

Review details

Suppressed comments (1)

src/RustPlusBot.Features.Connections/Listening/IRustServerConnection.cs:70

• Same as the team send: the return doc says "issued" but the method is bounded by a timeout waiting for an acknowledgement/response; aligning the wording helps set correct expectations for callers.

    /// <summary>Sends a message to in-game clan chat.</summary>
    /// <param name="message">The message text to send.</param>
    /// <param name="timeout">How long to wait for the send to be acknowledged.</param>
    /// <param name="cancellationToken">A cancellation token.</param>
    /// <returns>A task that completes when the send has been issued.</returns>
    /// <remarks>Like <see cref="SendTeamMessageAsync"/>, this surfaces failures to the caller and is bounded by <paramref name="timeout"/>.</remarks>
    Task SendClanMessageAsync(string message, TimeSpan timeout, CancellationToken cancellationToken);

• Files reviewed: 6/6 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[HandyS11]

Fixed in 464d698, on both methods.

Verified against the library before changing the wording — decompiling RustPlusApi.RustPlus (2.0.0-beta.8) shows both sends routed through ProcessRequestAsync:

public async Task<Response<TeamMessage?>> SendTeamMessageAsync(string message, CancellationToken cancellationToken = default)
{
    AppRequest request = new AppRequest { SendTeamMessage = new AppSendMessage { Message = message } };
    return await ProcessRequestAsync(request, delegate(AppMessage r) { ... });
}

So the task completes when the server's AppMessage response arrives, not when the bytes are written — "issued" was wrong.

Worth noting this is more than a wording nit: "issued" is exactly the fire-and-forget reading that made the unbounded await look harmless, which is what let a single unanswered send park a relay loop forever. The docs now say:

A task that completes when the server has acknowledged the send, not when it was written to the socket.