backend/src/ee/services/project-events/project-events-sse-service.ts
[P0] Readable doesn’t expose closed/close() semantics the way ServerResponse/Writable do, so the repeated checks of client.stream.closed / stream.closed can behave unexpectedly (always falsy) and prevent TTL refresh / pings / cleanup from running as intended.

This matters after this PR because you now rely on stream.closed to skip work and close() to end the connection; on Node streams you generally want stream.destroyed and/or stream.readableEnded.

Also appears at backend/src/ee/services/project-events/project-events-sse-service.ts:154-156, backend/src/ee/services/project-events/project-events-sse-service.ts:229-231, backend/src/ee/services/project-events/project-events-sse-service.ts:333-337.

backend/src/ee/services/project-events/project-events-sse-service.ts
[P2] The lock acquisition TTL jumped from 150ms to 5000ms. If the intent is to avoid lock churn under load, it’s worth double-checking this doesn’t unintentionally increase contention or block other subscribers longer than needed (especially since retryCount: -1 retries indefinitely). If 150ms was too low, consider documenting why 5000 is the right value here.

backend/src/ee/services/project-events/project-events-sse-service.ts
[P1] Destroying the stream on backpressure (!stream.push) will terminate the SSE connection for any temporary slow client and can be triggered by a malicious client that intentionally stops reading (easy to do with SSE). That’s probably acceptable as a protective measure, but it’s a behavioral change from “drop event” to “disconnect client”. If that’s intended, it may be worth logging at warn with project/client context so operators can distinguish normal disconnects from abuse.