Improve default IsValidResponseToDeserialize implementation #560
Conversation
… correct response content type
I'm fine to keep it |
rose-a
changed the title
Co-authored-by: Ivan Maximov <[email protected]>
Co-authored-by: Ivan Maximov <[email protected]>
Thanks, I believe it's all corrected now. |
…om/mikocot/graphql-client into bugfix/ensure-responsecontent-type
|
hm, something doesn't seem right in the workflow, it has timeout at the default GH time limit of 6h, while the previous run was ok |
|
Yep, |
|
hm, maybe a deadlock in xunit? I've seen with some asp.net core integration tests. It would only happen if several tests used the same classfixtures of custom WebApplicationFactory. In ended up to be bound to OTEL tracing and the workaround was to not configure it for testing. However, the same might happen with other 'shared' components. According to xunit authors it's intentional... It might happen only on some machines depending on the amount of cores and runner setup. On the other hand when I run all the tests locally I get some failed ones, unrelated to my changes, so I might be having something missing in the environment, didn't have time to investigate. |
|
can you restart the workflow? I dont seem to have rights |
As mentioned in issue #554 the default implementation of
IsValidResponseToDeserializecurrently does not verify if the response actually can be deserialized, regardless of its name.As it's a logical OR it completely ignores the ContentType as long s the status matches Ok or BadRequest. At the same time it's possible that a server or any other component even before reaching the server returns one of those statuses in incorrect ContentType. Such behavior ends up with an ugly runtime exception, while it can be easily handled.
I also made this method more readable and debuggable. It's discussable if AcceptedResponseContentTypes should be editable and exposed.