req_not_found when attaching

[nisbus]

I'm not sure if anything changed but at least now when I try to attach to the container I get the following error:
{<0.1104.0>,{error,req_not_found}}

I have a gen_server that creates/starts a container and then tries to attach to it for monitoring.
Create and start work fine, then I call the attach_stream_with_logs:

handle_cast(monitor, #container{id=CID}=State) ->
    docker_container:attach_stream_with_logs(CID),
    {noreply, State};

In my log output I see this:

17:45:16.688 UTC [info] api call: {post,stream} http+unix://%2Fvar%2Frun%2Fdocker.sock/containers/545f5f3e1f54bbd19a98bf2a2eadc079666802b4059a457573e2406c433b496a/attach?stream=true&logs=true&stdout=true&stderr=true
CAUGHT EXIT PID = <0.1104.0>, Self = <0.1088.0>, normal
17:45:16.751 UTC [info] Received {<0.1104.0>,{error,req_not_found}}

The caught exit is in the same gen_server:

handle_info({'EXIT', _Pid, Reason}, #container{service=Service, 
					   restart_counter = Counter
					  } = State) -> 
    case _Pid == self() of
	false ->	    
	    io:format("CAUGHT EXIT PID = ~p, Self = ~p, ~p~n", [_Pid, self(), Reason]),
	    {noreply, State};
.......

and the received line is from another handle_info:

handle_info(_Info, State) ->
    lager:info("Received ~p~n", [_Info]),
    {noreply, State}.

the req_not_found message is from Hackney but I don't know why that would be, if I check the state of the hackney_manager I see that the ref is there.

Ways to reproduce:

• docker pull nginx (just for testing)
• clone VEO git clone https://github.com/nisbus/veo
• checkout api branch git checkout api
• run make
• in the erlang shell run:

[H|[H1|_]] = settings:get_applications().
container_sup:add_service(H1).

You should now see the issue although sometimes I also see checkout_timeout for various operations (which I've "solved" by setting the recv_timeout = infinity in the erldocker_api OPTIONS).

Any help on this would be appreciated (or pointers to how I can fix it and contribute).

Thanks

[nisbus]

It seems the issue was just hackney configs for the pool, since the streaming methods shouldn't close connections and the config was set to 1 connection only.