fix(nvhttp): non-blocking TLS shutdown in SunshineHTTPS destructor

[awerty-noob]

Description

The HTTPS server (port 47984) can permanently stop accepting connections after certain Moonlight clients connect.

When a SunshineHTTPS connection object is destroyed (right after a response is written with close_connection_after_response), its destructor performs a synchronous TLS shutdown. After the server writes its own close_notify, SSL_shutdown() waits for the peer's close_notify via a blocking read_some() → poll(fd, POLLIN, -1) on the blocking socket. Clients that keep the connection open after receiving a response — the Moonlight HTTP connection pool (Android app, Moonlight-Switch, Moonlight-N3DS, …) — never send a close_notify, so the single io thread of the HTTPS server blocks forever. Every later connection times out (Moonlight: host reachable, app list authentication unavailable, HTTP timeout), the 47984 listen backlog grows, while 47989/RTSP/streaming keep working and the process appears healthy.

I confirmed this by resolving the hung thread's stack from a core dump plus debug symbols:

io_context::run()
  → reactive_socket_send_op::do_complete          (response just sent)
    → Response::~Response → ~Session → Connection released
      → ~SunshineHTTPS() → stream::shutdown()
        → ssl::detail::io<shutdown_op>
          → basic_stream_socket::read_some        (socket is blocking)
            → socket_ops::sync_recv1 → poll_read(s, -1)   ← hangs forever

I also reproduced it locally with a minimal client that sends GET /serverinfo and then keeps the connection open: the server stops responding within seconds and stays wedged until restart.

The fix marks the underlying socket non-blocking before shutdown() so the attempt returns immediately with would_block instead of blocking indefinitely; the close_notify is still written best-effort and the socket closes right after. The error_code overload is used because the destructor is noexcept and the throwing overload could terminate the process (also flagged by the SonarQube quality gate, which should now pass).

Screenshot

N/A (no UI changes)

Issues Fixed or Closed

• Fixes Sunshine connections fail after using certain Moonlight clients #5289

Roadmap Issues

N/A

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

Testing done manually: with the stock binary the reproduction above wedges the server; with this fix the server stays responsive in the same scenario (repeated /serverinfo probes return 200 OK), and normal requests, pairing and streaming are unaffected.

AI Usage

Please see the AI usage policy.

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

The debugging (core dump analysis, reproduction, fix) was performed with AI assistance; I reviewed and verified every step locally before submitting.

[ReenigneArcher]

Thank you for the PR submission, but it looks like you used AI to create this PR.

Please read and follow our Contributing guidelines and specifically our AI Usage policy.

Additionally, please update the PR to use the correct template. You can find it at https://github.com/LizardByte/.github/blob/master/.github/pull_request_template.md?plain=1

[awerty-noob]

Thanks for the review! I've now followed the contributing guidelines and updated the PR:

• Rewrote the description using the standard PR template.
• Filled in the AI Usage section honestly (Heavy): the debugging and fix were AI-assisted, but every step — root cause analysis, local reproduction, and the verification that the fix keeps the server responsive — was reviewed and confirmed locally before submission.
• Fixed the SonarQube issue on the new code: lowest_layer().non_blocking(true) was changed to the error_code overload, since the throwing overload could terminate the process from the noexcept destructor.

Summary of change (12 insertions in src/nvhttp.h): set the socket non-blocking before the synchronous shutdown() in ~SunshineHTTPS(), so the destructor can no longer block forever waiting for the peer's close_notify on the single io thread of the HTTPS server.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud