Redis connection leaks fixed and abort signals restored
A critical Node.js garbage collection bug masking client disconnects has been bypassed, and Redis connection pooling should eliminate resource leaks during realtime streaming.
Realtime streaming was quietly bleeding Redis connections, and client disconnects weren't registering due to a deep Node.js bug breaking the abort signal chain. A single shared Redis connection is now used for quick operations, while dedicated streaming connections are immediately severed when finished. Simultaneously, a new abort signal wired directly to the underlying Express response guarantees that the server knows exactly when a client drops off. Server resources are preserved, preventing connection exhaustion and runaway stream processing after a user closes their browser. These improvements land in the webapp's realtime streaming infrastructure.
View Original GitHub Description
Pool Redis connections for non-blocking ops (ingestData, appendPart, getLastChunkIndex) using a shared singleton instead of new Redis() per request. Use redis.disconnect() for immediate teardown in streamResponse cleanup. Add 15s inactivity timeout fallback.
Fix broken request.signal in Remix/Express by wiring Express res.on('close') to an AbortController via httpAsyncStorage. All SSE/streaming routes now use getRequestAbortSignal() which fires reliably on client disconnect, bypassing the Node.js undici GC bug (nodejs/node#55428) that severs the signal chain.