No notification of down state when handling an SSE connection.

[kinyoklion]

Prior to PR #197 when a gun_down was received that would result in the shotgun process exiting. An application using shotgun for SSE could monitor the PID and use the 'DOWN' event for error handling and re-connection.

Now shotgun transitions into a done state and the application is not aware that there is any issue.

References

Monitoring:
https://github.com/launchdarkly/erlang-server-sdk/blob/80206be388d7b8810b6e761f82c61774b77cfe29/src/ldclient_update_stream_server.erl#L170

Handling Down:
https://github.com/launchdarkly/erlang-server-sdk/blob/80206be388d7b8810b6e761f82c61774b77cfe29/src/ldclient_update_stream_server.erl#L92

One work-around is to poll the process periodically to see if it is still active:
https://github.com/knocklabs/erlang-server-sdk-2025-08/pull/1/files

But this isn't ideal.

Potentially we could have an option to disable this down state, so that the process will exit as it previously did.
Or some way of getting notified about the state transition?

[elbrujohalcon]

@mkrusemark: What do you think?

[elbrujohalcon]

@kinyoklion: I think that the addition of an option to allow_reopening => boolean() would be my preferred solution. The option would be checked before entering the down state and if it's false, that would terminate the gen_statem process.

But I would still wait for @mkrusemark's opinions (and maybe others) on the subject.

[mkrusemark]

@mkrusemark: What do you think?

I would prefer a proper return code and have synchronous error handling. Otherwise another process has to monitor the shotgun process (solution 1) and the actual http client process has to query the state of shotgun before sending a request. But the shotgun process is already closed so there is no chance of a reuse by reopening the connection and keep the PID in process states.

What about sending failure messages to registered processes? This would be a generic approach to handle with failures. And it would support the requested monitoring pattern. I know this is a complex approach.

For sure the lean approach is to add the allow_reopening option. It's not my preferred solution. It introduces more state that a developer has to be aware of.

[elbrujohalcon]

I see… well… since @kinyoklion kindly submitted a PR, I went on and merged it. Of course, we can implement a better solution if needed.

[kinyoklion]

I do think something like this could be a good idea in the future. But similar to gun's transition it would need to be either a 2.0 or optional. The initial reopen change was not a backward compatible change for consumers of this library using it for SSE and it caused a major bug.

Being as the only way to manage these connections currently is monitoring the pid, then anything that results in a failure in that mechanism will introduce major bugs to consumers of the library.

But if it is a 2.0, and you know it requires handling new info events, then that would be a different story.