dunglas / mercure / 24780844452 / 1
84%
master: 93%

LAST BUILD BRANCH: main
DEFAULT BRANCH: master
Ran
Files 23
Run time 1s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 84.096% (+0.1%) from 83.973%
24780844452.1

push

github

web-flow 
fix(subscribe): drain SSE subscribers naturally on hub shutdown (#1212)

On hub shutdown (Caddy "stopping" event, pod receiving SIGTERM, graceful
config reload), the subscriber select loop no longer observes
h.ctx.Done() when writeTimeout is enabled. Existing SSE connections
keep running until either the client disconnects or the per-connection
disconnection timer fires (derived from writeTimeout, and optionally
shortened by JWT expiry).

Rationale: a rolling update of a hub replica with active SSE
subscribers used to close every connection at once, producing a
reconnect storm on the ingress and on the transport. Since each
connection already has a write deadline that will close it on its own,
letting shutdown drain at the same pace is indistinguishable from
steady-state churn — no storm, no browser-side EventSource error.

The hard deadline stays with the orchestrator: k8s
terminationGracePeriodSeconds (or equivalent) SIGKILLs the process if
draining takes too long. Operators who want the drain benefit just bump
that value to >= writeTimeout + margin; operators who keep the default
30s see the same effective behavior as before (SIGKILL instead of an
internal force-close — indistinguishable to SSE clients).

When writeTimeout is disabled (0) there is no disconnection timer, so
we keep observing h.ctx.Done() on that path — otherwise
http.Server.Shutdown would hang indefinitely on active handlers.

Tests assert both semantics: shutdown with writeTimeout set keeps
subscribers connected; shutdown with writeTimeout=0 still closes them.

1745 of 2075 relevant lines covered (84.1%)

51.29 hits per line

Source Files on job 0 - 24780844452.1