[BUG] ValidationApiException.Content deserialization (ProblemDetails) bypasses IHttpContentSerializer
Describe the bug
ValidationApiException.Content deserialization (ProblemDetails) is now hardcoded in ValidationApiException.Create() and uses the System.Text.Json.JsonSerializer.Deserialize<ProblemDetails>() no matter whether there is any IHttpContentSerializer set.
public static ValidationApiException Create(ApiException exception)
{
if (exception is null)
throw new ArgumentNullException(nameof(exception));
if (string.IsNullOrWhiteSpace(exception.Content))
throw new ArgumentException("Content must be an 'application/problem+json' compliant json string.");
var ex = new ValidationApiException(exception);
if(!string.IsNullOrWhiteSpace(exception.Content))
{
ex.Content = JsonSerializer.Deserialize<ProblemDetails>(exception.Content!, SerializerOptions);
}
return ex;
}
The original implementation used to use IHttpContentSerializer for ProblemDetails deserialization. We use the IHttpContentSerializer for some custom-transformations of the incoming ProblemDetails, which is no longer possible.
public static async Task<ValidationApiException> Create(ApiException exception)
{
return new ValidationApiException(exception)
{
Content = await exception.GetContentAsAsync<ProblemDetails>().ConfigureAwait(false)
};
}
Expected behavior
ValidationApiException.Content being deserialized using the configured IHttpContentSerializer.
Workaround
You can call validationException.GetContentAsAsync<ProblemDetails>() on your own. It uses the IHttpContentSerializer and can help you get the result you need.
We just hit this too, I expected Newtonsoft to be used to deserialize problem details extensions when Newtonsoft was configured, but we got System.Text.Json.JsonElement types instead for the objects in the Dictionary<string, object> Extensions property.
It is fine once you know about it, but it is a pitfall and we now have to have code in place to handle both Newtonsoft and SystemJson in case Refit changes this behavior in the future.