1

This question relates specifically to .NET 7+ but it also touches on HTTP basics, so any input is welcome. Also: i tend to do a lot of googling myself before resorting to asking a new question. If my google-fu has left me yet again, i'm more than happy to accept links to external resources that i've overlooked.

I have an MVC endpoint that returns IAsyncEnumerable<int>. Let's assume that what the endpoint does, is reading rows from a table in a database. The database driver supports querying rows from a cursor using IAsyncEnumerable so i can basically do something like

[HttpGet]
public async IAsyncEnumerable<int> SomeEndpoint() {
  await foreach (var row in PerformSelectQuery())
    yield return int.Parse(row[0]);
}

So far so good: .NET and System.Text.Json handles it all well: It sets Transfer-Encoding to chunked and starts writing the response as soon as the first row gets returned from the database. I like that, because I don't have to do any buffering so I don't waste memory, and the client can start parsing the result faster (if it supports it).

Let's say: I did a crappy job and the column may contain null values. That would cause an exception to be raised by int.Parse say, in row #24645 out of 90000.

That's a problem:

.NET just kills the connection. Clients like Postman say the request has been aborted. And I can't blame them: There's no way of knowing what went wrong.

I can catch any exceptions (or do other error handling) in my foreach and, if needed, just yield break, causing the request to fail silently. Again, the client has no idea that the result is incomplete and an error ocurred.

I'm not even sure that's better than having the request fail completely. At least then, the client knows something went wrong.

My current solution is to wrap the int (or whatever i return) in a kind of Result/Option monad. That then gets serialized to the stream instead of the raw value. This way, i can catch an error, yield it as such from my action and then decide to either abort with a yield break, or continue down the table. The specific format of the wrapper is also tricky (polymorphic serialization, yay!) but not really subject of this question.

What other options do I have? I've read a little about the Trailer header, which seems like it's the right thing to do but

  • it apparently has little to no support with existing clients
  • I can only imagine how weird usage (from a client) must be
  • I have no idea how i would set these trailers in my controller action. The "chunking" is all done internally, so how - in my foreach - would i add error information to the trailer?
  • There seems to be no standarized way of reporting errors (gRPC has a little on it, but i'm not implementing a gRPC service).
  • And finally, i still can't report a different HTTP status code since in HTTP, that is not a header at all.

EDIT: I have figured out how to enable and write trailers from my function using Response.AppendTrailer, but I need to support HTTP/1.1 and since .NET doesnt support Trailers for HTTP < 2 at all, this won't work anyways :(

Funnily enough, i have noticed that here: Clarification on how IAsyncEnumerable works with ASP.NET Web API two people have started to ask the same question in the comments. Without any reply. Is that such an obscure thing? Is no one streaming IAsyncEnumerable to the client? Or is everyone who does just writing flawless code that never fails? :D

Does anyone know of any best practices for this scenario? Does anyone have experience with a similar problem?

Ar Es
  • 389
  • 3
  • 12

2 Answers2

1

I don't think I agree that this is anything to do with HTTP. Your data model can't represent a missing value with the clarity you desire; as long as the response is syntactically valid JSON, HTTP doesn't care (in the sense that Content-Type: application/json implies a well-formed response). I don't think looking to the HTTP spec for the ability to represent an interrupted response is the way to go; this is a data modelling issue. I don't agree that it's anything to do with streaming a response either; the representational issue would be the same with a synchronously serialized response - an array of ints in C# is an array of ints in JSON.

So, in answer to:

How do i notify a client that out of maybe thousands of results in the stream, the 832nd had an error?

The answer from my point of view seems to be "However you like."* (*with the constraint that an answer must be expressed as syntactically valid JSON)

Tom W
  • 5,108
  • 4
  • 30
  • 52
  • I think you're onto something here: i seem to be mixing a few things here. One being the representation of errors in a collection, and i absolutely agree with you: I can do that however i want (as long as it ends up being valid and I document it appropriately for clients to deal with.) The other thing is: how do i deal with serialization errors after headers have been sent. I guess i was hoping two kill two birds with one stone by resorting to a HTTP feature (trailers) and do so in a Content-Type agnostic way. – Ar Es May 04 '23 at 09:02
  • Seing as how Trailers are still a barely supported feature and awkward to use anyways, I guess I'll stick to my current approach for all failures i _can_ handle As for unexpected errors, i guess aborting the request (and logging server side) is the only sensible thing to do. This comment here: https://github.com/dotnet/aspnetcore/issues/32483#issuecomment-849667823 basically says as much: "[..] t's also entirely possible that serializing POCOs throws because one of the property getters throws while the response headers have already been sent. [..]" – Ar Es May 04 '23 at 09:13
  • Marking this as the answer since it "was the most helpful in finding your solution" – Ar Es May 04 '23 at 09:14
0

You have a few options that you didn't seem to explore in the question:

  1. Don't return anything that's not an int from PerformSelectQuery
  2. If you don't have control over the return types/values from PerformSelectQuery add var row in PerformSelectQuery().Where(r => int.TryParse(r[0], out var _))
  3. Or something similar: if (int.TryParse(row[0], out int i) yield return i;
  4. If PerformSelectQuery returns a non-int when there IS an error, consider changing the endpoint to return a IAsyncEnumerable<int?> so that the client will be able to understand there are nulls when something goes wrong.

If your psuedo-code in this question isn't telling us the whole story, consider posting more code.

Bron Davies
  • 5,930
  • 3
  • 30
  • 41
  • Ah, i was afraid this was going to happen. The question is _not_ about how to handle errors within the function. I understand how to use TryParse. I can just wrap it all in a catch-all block (In fact, i would _have_ to, since what if there's something i _cant_ foresee like someone taking a sledgehammer to the network switch ;)) The question is more about "How do i notify a client that out of maybe thousands of results in the stream, the 832nd had an error?" Your 4th suggestion is kind-of what i'm doing right now, except instead of using ```null``` to represent an errors, i .... – Ar Es May 03 '23 at 15:15
  • .... wrap the result in something like ```class Result { int? Value {get;} Exception? Error {get;} bool Success {get;} }``` – Ar Es May 03 '23 at 15:15