Handling transport-level exceptions like OperationCanceledException in ApiResponse<T>

[lucaseeeduardo]

Hi there,

First of all, thanks for maintaining Refit — it's been very helpful.

Following with my question, I have noticed that transport-layer exceptions (such as OperationCanceledException from a timeout or IOException from interrupted network reads) are not captured into ApiResponse.Error when using IApiResponse or ApiResponse. Instead, they bubble up and must be handled with an external try/catch, even when using Refit’s Task<ApiResponse> style.

What I expected
Since deserialization errors are wrapped into an ApiException and stored in the Error field of the response, I expected transport errors like timeouts or stream read failures to behave the same — in other words, for ApiResponse.IsSuccessful to be false, and Error to hold the wrapped exception.

What currently happens
Looking at the current source, particularly this part of BuildCancellableTaskFuncForMethod:

if (IsBodyBuffered(restMethod, rq))
{
    await rq.Content!.LoadIntoBufferAsync().ConfigureAwait(false);
}

resp = await client
    .SendAsync(rq, HttpCompletionOption.ResponseHeadersRead, ct)
    .ConfigureAwait(false);

Any exception that occurs here — such as a TaskCanceledException due to an HTTP timeout — escapes the method entirely, because it happens before the existing try/catch block that wraps deserialization.

As a result, the calling code must explicitly catch transport-layer exceptions, even when using Refit’s higher-level response wrappers like IApiResponse.

Suggestion
It would be a meaningful improvement if SendAsync(...) and LoadIntoBufferAsync() were moved inside a try/catch block, similar to how deserialization exceptions are handled.

For example:

try
{
    if (IsBodyBuffered(restMethod, rq))
        await rq.Content!.LoadIntoBufferAsync().ConfigureAwait(false);

    resp = await client
        .SendAsync(rq, HttpCompletionOption.ResponseHeadersRead, ct)
        .ConfigureAwait(false);
}
catch (Exception ex) when (ex is OperationCanceledException || ex is IOException)
{
    var apiEx = await ApiException.Create(
        ex.Message,
        rq,
        rq.Method,
        null,
        settings,
        ex
    ).ConfigureAwait(false);

    return ApiResponse.Create<T, TBody>(
        resp: null!,
        body: default,
        settings: settings,
        apiException: apiEx
    );
}

That way, the Refit client could fully encapsulate network and protocol-level exceptions inside the ApiResponse, making error handling more uniform and idiomatic.

Would the maintainers be open to a change or PR in this direction?

Thanks again!