SocketException: Reading from a closed socket crash

[aaravgarg]

Summary

• Fix crash in sendStreaming when a SocketException ("Reading from a closed socket") is thrown
• Return a synthetic 503 StreamedResponse instead of letting the exception propagate as a fatal crash
• This handles the case where the socket is closed mid-request (e.g., server drops connection, network switch)

Crash Stats

• Events: 3,021
• Users affected: 533
• Crashlytics: View in Console

Test plan

• Verify streaming requests still work normally
• Test with intermittent network (should gracefully return 503 instead of crashing)

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request effectively addresses a crash caused by an unhandled SocketException in sendStreaming by catching the exception and returning a synthetic 503 response. This is a good approach to gracefully handle network interruptions during streaming requests. My review includes one suggestion to improve observability by logging the caught exception, which is important for monitoring since these errors will no longer appear as crashes.

[gemini-code-assist]

While this change correctly prevents the crash, it silently swallows the SocketException. This means you will lose visibility into these network errors, which were previously reported as crashes. It would be beneficial to log the exception to aid in future debugging and monitoring.

First, capture the exception object. Then, you can log it using a suitable logging utility from your project (e.g., DebugLogManager.logWarning).

on SocketException catch (e, stackTrace) {
  // You may need to import your logging utility
  DebugLogManager.logWarning('send_streaming_socket_error', {
    'error': e.toString(),
    'stackTrace': stackTrace.toString(),
    'request_url': request.url.toString(),
  });
  // ... rest of the block
}

Suggested change

	} on SocketException {
	} on SocketException catch (e, stackTrace) {

[beastoin]

Hey @aaravgarg! Thanks for this SocketException crash fix — large impact (3,021 events, 533 users).

We're tidying up stale PRs — this one has been open 8 days with untested test plan and no demo. The gemini review noted the fix silently swallows the exception, which could hide issues.

Could you run the test plan, consider the review feedback, and add a demo? Feel free to reopen once ready!

[github-actions]

Hey @aaravgarg 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

• Project standards — Ensuring consistency across the codebase
• User needs — Making sure changes align with what our users need
• Code best practices — Maintaining code quality and maintainability
• Project direction — Keeping aligned with our roadmap and vision

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community! 💜