Please confirm the following.
What version of the Modrinth App are you using?
Historical failures include 0.19.1; currently 0.20.4 (flood not reproduced in current verification)
What operating systems are you seeing the problem on?
MacOS
Describe the bug
Historical macOS launcher logs contain substantial repetitive connection-error reporting:
- A September 1, 0.19.1 session recorded 460 connection-refused errors between startup and exit, alongside server-ping timeouts and unexpected EOF errors.
- Across the available archive, friends-websocket errors total 4,678. The largest session has 978 spread across March 7–14. That is a multi-day recurrence, not evidence of 978 errors per second.
- Several sessions also contain repeated unreachable-host, DNS, timeout, and reset errors associated with saved-server availability.
Most connection-refused records have empty span traces, so their precise origin cannot be assigned from those messages alone. They cannot all be attributed to server pings or the friends socket.
Current 0.20.4 verification connected the friends socket successfully and did not reproduce these floods. This report requests investigation and regression coverage; it does not claim a newly reproduced 0.20.4 flood.
Steps to reproduce
A deterministic current-release reproduction is not established. Historical failures occurred while the app remained open across network interruptions and unavailable saved servers.
Suggested controlled reproduction: run the app against a test websocket/server, inject connection reset, close, timeout, DNS failure and refusal, and observe reconnect/probe frequency and log output. Include sleep/wake and reconnect transitions. These fault-injection tests have not been run in the user's live environment.
Expected behavior
Unavailable connections should produce a meaningful offline state and bounded, cancellable retries, without repetitive error floods or duplicate probe/reconnect loops. Genuine unexpected failures should retain useful diagnostics and recovery should restore state.
Additional context
Source investigation and proposed correction
Friends receive loop, v0.20.4 logs receive errors and continues polling. Connection-generation checks and post-loop cleanup already exist. Test the stream’s terminal-error behavior before changing reconnect logic; the historical records alone do not prove a tight loop.
On terminal transport failure, consider leaving the read loop so current-generation cleanup runs. Ensure a single reconnect owner, bounded backoff with jitter, and cancellation on account change/shutdown. Include subsystem, operation, connection generation, and error class in diagnostics without credentials or session-bearing URLs.
For unavailable saved game servers, use offline UI state and bounded rechecks. Preserve diagnostic counts while logging meaningful state transitions; investigate repeated identical probes rather than merely lowering log severity.
Suggested acceptance tests
- Reset/close/timeout a mock socket: no busy polling or repeated terminal-error loop.
- Reconnect succeeds, restores state, and emits one recovery transition.
- A stale reader cannot clear or overwrite a newer connection.
- Concurrent callers cannot create duplicate reconnect loops.
- Sleep/wake, intermittent connectivity, permanent refusal and DNS failure remain bounded and cancellable.
- Repeated UI visits do not multiply probes for the same offline server.
- Unexpected failures remain diagnosable.
The support portal’s network-troubleshooting guidance was reviewed. Download concurrency was briefly reduced, then restored to the normal 10; current verification succeeded at 10. That mitigation does not establish a fix for historical connection floods. No saved servers were deleted or error logging disabled. This report contains proposed corrections and tests, not an implemented patch.
Please confirm the following.
What version of the Modrinth App are you using?
Historical failures include 0.19.1; currently 0.20.4 (flood not reproduced in current verification)
What operating systems are you seeing the problem on?
MacOS
Describe the bug
Historical macOS launcher logs contain substantial repetitive connection-error reporting:
Most connection-refused records have empty span traces, so their precise origin cannot be assigned from those messages alone. They cannot all be attributed to server pings or the friends socket.
Current 0.20.4 verification connected the friends socket successfully and did not reproduce these floods. This report requests investigation and regression coverage; it does not claim a newly reproduced 0.20.4 flood.
Steps to reproduce
A deterministic current-release reproduction is not established. Historical failures occurred while the app remained open across network interruptions and unavailable saved servers.
Suggested controlled reproduction: run the app against a test websocket/server, inject connection reset, close, timeout, DNS failure and refusal, and observe reconnect/probe frequency and log output. Include sleep/wake and reconnect transitions. These fault-injection tests have not been run in the user's live environment.
Expected behavior
Unavailable connections should produce a meaningful offline state and bounded, cancellable retries, without repetitive error floods or duplicate probe/reconnect loops. Genuine unexpected failures should retain useful diagnostics and recovery should restore state.
Additional context
Source investigation and proposed correction
Friends receive loop, v0.20.4 logs receive errors and continues polling. Connection-generation checks and post-loop cleanup already exist. Test the stream’s terminal-error behavior before changing reconnect logic; the historical records alone do not prove a tight loop.
On terminal transport failure, consider leaving the read loop so current-generation cleanup runs. Ensure a single reconnect owner, bounded backoff with jitter, and cancellation on account change/shutdown. Include subsystem, operation, connection generation, and error class in diagnostics without credentials or session-bearing URLs.
For unavailable saved game servers, use offline UI state and bounded rechecks. Preserve diagnostic counts while logging meaningful state transitions; investigate repeated identical probes rather than merely lowering log severity.
Suggested acceptance tests
The support portal’s network-troubleshooting guidance was reviewed. Download concurrency was briefly reduced, then restored to the normal 10; current verification succeeded at 10. That mitigation does not establish a fix for historical connection floods. No saved servers were deleted or error logging disabled. This report contains proposed corrections and tests, not an implemented patch.