Safari 27: NextDNS Logs live stream breaks when changing the selected device

Hello,

I believe there is a bug in the NextDNS web dashboard's live Logs streaming when using Safari 27 on macOS 27.

The live Logs stream works normally when the Logs page is first loaded. However, when I change the selected device, the existing Server-Sent Events (EventSource) connection is closed and the replacement stream intermittently fails to establish.

Safari Web Inspector shows this sequence:

• The /logs API request succeeds with HTTP 200.
• The initial /logs/stream request successfully establishes an authenticated HTTP/3 connection and returns 200 text/event-stream.
• After changing the selected device, a replacement /logs/stream request can appear with Status: — and no response headers.
• That failed request can terminate almost immediately, after which another /logs/stream request may successfully return 200.
• The problem is intermittent, but it is strongly associated with changing the selected device while live streaming is enabled.

I have already ruled out the obvious Safari privacy-related causes: content blockers are disabled, Lockdown Mode is disabled, Safari's privacy-protection reload option is disabled, and HTTP/3 is enabled and working.

I also inspected the JavaScript bundle currently served by the dashboard. The Logs component appears to clear its stream state when the selected device changes, while the EventSource cleanup explicitly closes the existing connection. This appears to cause the old stream to be torn down as part of the device change, after which the new stream is not always successfully established.

There also appears to be an EventSource cleanup issue where the error listener that is registered is not the same function reference used when attempting to remove it.

Could you please investigate the Logs page's EventSource lifecycle when the selected device changes?

The expected behavior would be:

1. Cleanly close the EventSource associated with the old device.
2. Obtain the new /logs response and its meta.stream.id.
3. Automatically establish the new /logs/stream EventSource for the newly selected device.
4. Preserve the user's live-streaming state throughout the device change.
5. Properly remove the EventSource event listeners during cleanup.

This does not appear to be a DNS-resolution or HTTP/3 connectivity problem, because the same Safari session is successfully establishing HTTP/3 connections to the stream endpoint before and after the failure.

I have attached the current main.26bf8924.js dashboard bundle for reference. I am not attaching HAR files or Web Inspector screenshots because they contain account/session-specific request information.

Thank you.