Not receiving HTTP responses using Telsa + Hackney

Samuel-88

Hello all,
Hope everyone is doing all right!

I am working on an application that uses an API that does not support the keep-alive option on HTTP requests.

On average we send a couple million requests to that API every month. And about two hundred of those requests are sent, the other API receives it, and answers back very fast (~200 ms) but for some reason the answer does not arrive in our application. We are using Tesla with Hackney, and we have an internal library that actually sends the requests. The first thing we tried to do is to disable the pool of connections since the API does not handle keep alive.

Our configs are as follow in the application that uses the internal lib to do requests:

config :tesla, adapter: {Tesla.Adapter.Hackney, recv_timeout: 27_000, pool: false}
config :tesla, Module.PathToTheModule, adapter: {Tesla.Adapter.Hackney, recv_timeout: 27_000, pool: false}

And in the internal lib that actually does the requests:

config :tesla, adapter: {Tesla.Adapter.Hackney, recv_timeout: 27_000, pool: false}

The first thing that confuses me is which configuration will actually be used, the one in the original application that calls the lib that does the requests, or the actual lib that handles the requests? The Tesla client is built in the lib.

I thought about changing the HTTP client but not sure if it’s worth it. Has anyone gone through that? Does anyone have any tips?

Thanks a lot for any help,

2 comments

#http_client #http-requests #hackney #tesla

1 778 2

2025-12-05 14:18:36 UTC

Showing Posts 1 to 2

Show Best Posts
Show All (oldest first)
Show All (newest first)

Eiji

If you have config A and B and one of them overrides the other one, then the simplest way for you way to find it yourself without any help is to make a mistake in one of configuration and see if it affects your code. If not revert that change and just to be sure change second config. At least one of those changes should fail.

# Hackney -> HackHey
config :tesla, adapter: {Tesla.Adapter.HackHey, recv_timeout: 27_000, pool: false}

You should have an error that a module or it’s function is not available and that the module is not loaded.

I don’t know if it’s worth it .. Depends on how you see it …

If that’s the only problem and you are able to fix it then I do not see a need to do that other than a bigger code refactor
If you plan code refactor anyway then why not giving a try other hex dependency?
Salary you can offer me

More or less seriously, but the general rule is that you should be the only person to make decisions for you. Nobody who only give you “empty advice” would take responsibility for what you do. This applies not only to programming, but any topic around investing (time, money, resources etc.).

Depends on what you ask … Many developers made a code refactor at least once and with good library API it should be enough simple to not even touch tests and the rest of code. If you mean an edge-case with a custom server not supporting any commonly supported HTTP header then I guess that most people may at most heard about such case, but never had a chance to work on it.

The simplest way is to show some example code, but I guess that may take some time for some cases. You can always ask somebody for help and invite him to project. As a senior Elixir developer I’m helping with creating issues and pull requests in last 7 years:

Recently in May I have even done a major code refactor for a public repository:
https://github.com/davidkuhta/avatarex/pull/1

Here is my GitHub profile:

Post #1

rizwan_khalid

Hey @Samuel-88 , I hope you are fine.
Found this post to a very similar issue happening with me, did you by any chance find a solution for this? Is there a bug in the Tesla lib? Any advice / tip would be much helpful to me.

Thanks in advance.

Post #2

— All posts loaded —