Error Returned by Tesla.Adapter.Finch.request/6 is Not Always an Exception

[mdsebald]

I don't know if the problem is here or in Finch, so I'll start here, but feel free to direct me elsewhere.

The :error tuple returned by Finch.request() is not always an Exception, but Finch Adapter request() is expecting {:error, %Exception{}} on an error.

And so I get:

** (FunctionClauseError) no function clause matching in Exception.message/1
    (elixir 1.12.1) lib/exception.ex:58: Exception.message(%{reason: :disconnected})
    (tesla 1.4.1) lib/tesla/adapter/finch.ex:68: Tesla.Adapter.Finch.call/2
    (hardhat 0.2.0) lib/hardhat/trace.ex:71: anonymous fn/3 in Hardhat.Trace.call/3
    (opentelemetry_api 1.0.0-rc.2) src/otel_tracer_noop.erl:70: :otel_tracer_noop.with_span/5
    (tesla 1.4.1) lib/tesla/middleware/fuse.ex:86: Tesla.Middleware.Fuse.run/3
    (tesla 1.4.1) lib/tesla/middleware/retry.ex:88: Tesla.Middleware.Retry.retry/3
    (tesla 1.4.1) lib/tesla/middleware/follow_redirects.ex:46: Tesla.Middleware.FollowRedirects.redirect/3

Relevant Code

[teamon]

I think we could pass the underlying mint error as is without calling Exception.message/1

@adriankumpf Any thoughts of this?

[adriankumpf]

According to the function spec Finch should always return an Exception. Therefore an issue in the Finch repo might be a good idea.

But in general, I see no reason why we shouldn't pass on the underlying error.

[lukebakken]

Finch 0.8.0 will address this issue - https://github.com/keathley/finch/issues/142. I think this issue (#469) can be closed.

[mdsebald]

Finch 0.8.0 released. Closing issue