httpc: stream_start on an already running stream

[sirihansen]

Describe the bug
This is more of a question than a bug report at this time. We are using httpc to implement an SSE stream client. So we call httpc:request /5 with options [{stream,self},{sync,false}], then we wait for {http, {RequestId, stream_start, Headers}}, and after that we expect stream content or stream end messages. But every now and then we get another stream_start message. This can happen several minutes after we set up the stream and have received the first stream_start with the same RequestId. So the question is, is this normal and something that can be ignored, or should it be investigated?

To Reproduce
It happens every now and then both in our test- and prod environments, but I haven't (yet) found a way to reproduce it on demand.

Expected behavior
I did expect only stream content or stream_end (or errors) after the first stream_start message.

Affected versions
26.2

Additional context

[Whaileee]

I will take a look at this one. I have a theory, but need to verify it before I say anything specific

[Whaileee]

@sirihansen
Could you provide more insight on how the httpc stream is setup? What headers are used? Any detail that you feel could make a difference.
Thanks in advance

[sirihansen]

@Whaileee Sorry for the long delay - I missed the notification.

The stream setup contains nothing "strange" as far as I can tell. But here is an example:

httpc:request(get,{"https://...", [{"Authorization", "Bearer ..."}, {"x-locale","sv_SE"}]},[{timeout,infinity},{connect_timeout,5000}], [{stream,self},{sync,false}], myprofile)

The inets profile has the following options:

[{max_keep_alive_length,0},
 {max_sessions,400},
 {max_pipeline_length,0},
 {pipeline_timeout,0},
 {keep_alive_timeout,30000},
 {proxy,{{"...",3128},[]}}]

[Whaileee]

In the meantime, I've found out that this scenario is the result of using pipeline/keep-alive connection or redirection. When there is an interrupt in the already established connection (ex. httpd config reload), two stream_start messages are present without stream_end in between. This indicates that the connection was interrupted and resumed. Is there an stream_end message after the occurrence of double stream_start, or is there an {error, socket_closed_remotely}?
RequestId is associated with handler, so seeing the same RequestId twice suggests that the httpc_handler was reused for the connection.
Links:
httpc_manager:515 - retry_or_redirect_request
httpc_manager:763 - select_session

[sirihansen]

Ok. I'll have a look for stream_end or socket_closed_remotely and get back to you.

[sirihansen]

In the few cases where the stream is terminated from the server side, we get a stream_end message. So far I have not seen any {error, socket_closed_remotely} on a stream where we got a second stream_start. These are SSE streams, and in most cases the client is the one who closes the stream so there are not a lot of cases though.

[Whaileee]

I wouldn't worry, if there isn't an error message then, but I suppose you can always put some logs somewhere around the places that I provided, and see exactly what is happening, and why. If that satisfies you, may I ask to close the issue? One way or the other I'm happy to help, so feel free to ask.
Best regards,
Konrad

[sirihansen]

Ok, as long as there is nothing "wrong" I can just ignore these messages. It would possibly be nice if the docs would say that duplicate stream_start could occur in some situations. Anyway, please feel free to close the issue! Thanks for looking into it!

[Whaileee]

Thanks for the suggestion, this will definitely prevent confusion in the future