Cannot handle server error #91
Labels
bug
Something isn't working
Comments
|
@skyred can you please attach the original json of the server response? It is unclear where the cast error happens exactly. |
|
There are a few error responses bodies. Here is one: |
|
@skyred I was able to parse and error document from the json you attached, so the issue is probably not with parsing. Would you please attach trace logs? |
|
Actually disregard this. I know where it comes from. Will issue an update soon. |
|
@skyred Should be fixed in 4.0.0. Please confirm. |
|
Here is another error not being handled properly with 4.1.0. Basically, server crash, 500 status code, then the response is not json (server crashed, therefore, doesn't know to return JSON anymore)
example response body: |
|
Here is another error example, which should be very similar to the one above. |
|
Ack. Going to tackle it today. |
|
Hi @skyred, The library is failing with |
|
@sanekyy @shrop @frank06 @Inobtenio anyone have an opinion on the above question? |
This sounds like a good thing to do |
Merged
|
@skyred I decided to solve it differently. Now in case of an error status code if the content-type is incorrect, the client will not attempt to decode the body at all. All |
|
I looked up JSON:API specification, it didn't have a suggestion on how a client should handle a response without the correct media type. I left a message in Drupal slack channel to see if anyone has feedback. The approach in
Are you suggesting to sub-class |
|
I agree that silencing errors is not the best thing to do, but it is somewhat expected from the user code to at least check the response status once it's returned from the client. Technically I tend to think that this is a corner case which lies outside of JSON:API domain, so I don't have a strong opinion on that. The library is flexible enough to allow you to pick any error handling strategy you prefer. Consider using /// Use the standard routing
final routing = StandardRouting(Uri.parse('http://localhost:8080'));
/// Create the HTTP client. We're using Dart's native client.
/// Do not forget to call [Client.close] when you're done using it.
final httpClient = Client();
/// We'll use a logging handler to validate responses.
final httpHandler = LoggingHttpHandler(DartHttp(httpClient), onResponse: (r) {
if (r.body.isNotEmpty &&
r.headers['content-type'] != Document.contentType) {
throw SomeUserException('Invalid response content type');
}
});
/// The JSON:API client
final client = RoutingClient(JsonApiClient(httpHandler), routing); |
|
@skyred Thank you for using the package, BTW. Please let me know if you have any ideas on improving the DX. One thing I can think of is injecting some sort of final httpHandler = DartHttp(httpClient, responseValidation: RequireValidContentType());with some meaningful defaults. |
|
Hi @f3ath I think the issue I'm reporting is somehow related to this same issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
error_object.dartcannot handle server error like one in the screenshot below.The real server response is
402 Unprocessable Entity, but, if we try to catch the exception, we got_CastError (type 'int' is not a subtype of type 'String' in type cast)insteadThe text was updated successfully, but these errors were encountered: