When returning a binary stream, Socket hosting model's error handling isn't consistent with Http hosting model's #1533

New Issue

fergalmoran · 2025-08-09T17:20:30Z

fergalmoran commented

2025-08-09 17:20:30 +00:00

Originally created by @SteveSandersonMS on 7/6/2016

Both hosting models handle errors consistently and correctly for non-Stream responses.

But for Stream responses, if the invoked Node module throws an uncaught exception,

The Http hosting model handles it well, behaving the same as if you invoked callback(error, null) and ends up throwing an exception back in .NET land containing the error info
The Socket hosting model doesn't handle it well. It calls connection.end(errorInfoAsJson), but when this string gets back into .NET land, it just becomes the content of the result stream. It doesn't throw an exception like you'd expect.

This is because the Socket hosting model, when you return a binary string, just literally passes the binary data back to .NET without any encoding/prefix/suffix, so it doesn't even have a way to signal to .NET that the response for a given call should be regarded as an error. To solve this, consider adding a short prefix before the Stream-type responses that specifies whether the remaining data in the stream should be regarded as the success-case binary data, or a JSON string describing an exception to be thrown.

*Originally created by @SteveSandersonMS on 7/6/2016* Both hosting models handle errors consistently and correctly for non-`Stream` responses. But for `Stream` responses, if the invoked Node module throws an uncaught exception, - The `Http` hosting model handles it well, behaving the same as if you invoked `callback(error, null)` and ends up throwing an exception back in .NET land containing the error info - The `Socket` hosting model doesn't handle it well. It calls `connection.end(errorInfoAsJson)`, but when this string gets back into .NET land, it just becomes the content of the result stream. It doesn't throw an exception like you'd expect. This is because the `Socket` hosting model, when you return a binary string, just literally passes the binary data back to .NET without any encoding/prefix/suffix, so it doesn't even have a way to signal to .NET that the response for a given call should be regarded as an error. To solve this, consider adding a short prefix before the `Stream`-type responses that specifies whether the remaining data in the stream should be regarded as the success-case binary data, or a JSON string describing an exception to be thrown.

fergalmoran closed this issue

2025-08-09 17:20:30 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#1533