[PR #510] [MERGED] fix(rest): don't send a second response after a successful resume #498

New issue

Closed

opened 2026-10-15 13:01:02 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 13:01:02 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/wolf/pull/510
Author: @jdonaldson
Created: 9/21/2026
Status: ✅ Merged
Merged: 9/22/2026
Merged by: @ABeltramo

Base: stable ← Head: fix/resume-double-response

📝 Commits (1)

40858c3 fix(rest): don't send a second response after a successful resume

📊 Changes

1 file changed (+1 additions, -2 deletions)

View changed files

📝 src/moonlight-server/rest/endpoints.hpp (+1 -2)

📄 Description

Fixes #509.

resume() ended with an unconditional server_error<SimpleWeb::HTTPS>(response) at function scope, so the success path wrote two complete HTTP responses onto the same connection: 200 + resume XML from send_xml(), then 400 + error XML from server_error().

send_xml() calls response->write(...) and sets close_connection_after_response = true, and server_error() is itself a send_xml() with client_error_bad_request — so both were emitted back to back.

This moves the call into the else, which matches launch(), cancel(), and the other three server_error() call sites in this file (all already inside conditionals). git blame dates the line to cb0e168e (2025-04-04), the same commit that added the success-path send_xml() two lines above, so it looks like a leftover from that refactor.

Verification

Compiles clean against stable @ 2273b2e (built via docker/wolf.Dockerfile --target wolf-builder, 0 errors).
Behaviour change verified by reading only. I have not instrumented a Moonlight client to confirm how it reacted to the trailing 400 — it may well have been ignoring it, since the connection closes right after. What the change guarantees is that a successful resume is now distinguishable from a failed one at the protocol level.
No test added: the resume path needs a paired client and a live session, which the existing suite does not stand up. Happy to add one if you can point me at the right fixture.

Found while investigating re-entry into an already-running session (#501, #504). Not claiming it causes the CUDA-context crashes there — separate defect, noticed along the way.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/wolf/pull/510 **Author:** [@jdonaldson](https://github.com/jdonaldson) **Created:** 9/21/2026 **Status:** ✅ Merged **Merged:** 9/22/2026 **Merged by:** [@ABeltramo](https://github.com/ABeltramo) **Base:** `stable` ← **Head:** `fix/resume-double-response` --- ### 📝 Commits (1) - [`40858c3`](https://github.com/games-on-whales/wolf/commit/40858c3cea0231bf6b918b6d557e7427348331ec) fix(rest): don't send a second response after a successful resume ### 📊 Changes **1 file changed** (+1 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `src/moonlight-server/rest/endpoints.hpp` (+1 -2) </details> ### 📄 Description Fixes #509. `resume()` ended with an unconditional `server_error<SimpleWeb::HTTPS>(response)` at function scope, so the success path wrote two complete HTTP responses onto the same connection: `200` + resume XML from `send_xml()`, then `400` + error XML from `server_error()`. `send_xml()` calls `response->write(...)` and sets `close_connection_after_response = true`, and `server_error()` is itself a `send_xml()` with `client_error_bad_request` — so both were emitted back to back. This moves the call into the `else`, which matches `launch()`, `cancel()`, and the other three `server_error()` call sites in this file (all already inside conditionals). `git blame` dates the line to `cb0e168e` (2025-04-04), the same commit that added the success-path `send_xml()` two lines above, so it looks like a leftover from that refactor. **Verification** - Compiles clean against `stable` @ `2273b2e` (built via `docker/wolf.Dockerfile --target wolf-builder`, 0 errors). - Behaviour change verified by reading only. I have not instrumented a Moonlight client to confirm how it reacted to the trailing `400` — it may well have been ignoring it, since the connection closes right after. What the change guarantees is that a successful resume is now distinguishable from a failed one at the protocol level. - No test added: the resume path needs a paired client and a live session, which the existing suite does not stand up. Happy to add one if you can point me at the right fixture. Found while investigating re-entry into an already-running session (#501, #504). Not claiming it causes the CUDA-context crashes there — separate defect, noticed along the way. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 13:01:02 +00:00