Summary: A wrapped IllegalStateException from a session-invalidation-related failure is not detected by the SseBroadcaster , leading to an uncompleted CompletionStage entering the chain. This blocks further processing and results in undelivered events and memory leaks. The root cause is a combination of: Session-aware I/O silently failing, Lack of deep inspection of exceptions inside send(...) , and the broadcast chaining model depending on timely completion. This issue is difficult to detect at runtime and may remain unnoticed until severe resource exhaustion occurs. Steps: A SseEventSink is associated with a session-backed HTTP connection. The session is invalidated (e.g. due to timeout, logout, etc.). On the next broadcast(...) call: The send(...) method of the sink attempts to write to the AsyncOutputStream . This fails internally due to the invalidated session and would typically throw an IllegalStateException . However, the underlying ServletContainer wraps this exception into a RuntimeException , which itself is wrapped in a CompletionException. The exception is not propagated as a synchronous failure , nor is it recognized by the broadcaster or the sink. The send(...) method returns a CompletionStage that is never completed - it is the internal future of the WriteOperation of the AsyncOutputStream (-> DeferredOutputStream). This CompletionStage is passed into the broadcaster’s internal .thenCompose(...) chain. The result: the chain hangs indefinitely and all subsequent sinks never receive the broadcasted event . Important Technical Detail: In this case, the root cause ( IllegalStateException ) would normally lead the broadcaster to remove the sink correctly (as it does when sending to a closed sink, see SseEventOutputImpl ). But: The actual exception is wrapped and abstracted by the servlet container , And the broadcaster does not inspect or unwrap the exception deeply, Thus, the broadcaster fails to remove the faulty sink and continues including it in future broadcasts, Leading to hanging sends , buffer buildup , and eventually OutOfMemoryError . Workaround (Limited): We detect failures using the SseBroadcaster.onError(...) mechanism and close the affected sink manually. On the next event, send(...) then throws a synchronous exception, allowing the broadcaster to cleanly remove the sink. However, this only works if: The send(...) method actually throws or the stage completes exceptionally. In the scenario described above, neither occurs — instead, the stage remains pending forever.