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) {