fix(#252): close leftover ioredis handles so e2e jest exits cleanly (no forceExit) #254

Open

agent_coder wants to merge 1 commits from fix/252-e2e-open-handles into develop

Author	SHA1	Message	Date
claude code agent 227	8274720281	fix(server): close leaked redis sockets so e2e jest exits (#252 ) The full-AppModule e2e (apps/server/test/app.e2e-spec.ts) passed but jest never exited, burning CI to its timeout. Diagnosis (process._getActiveHandles after app.close()) showed exactly two ioredis sockets to :6379 still open after shutdown; everything else (BullMQ queues/workers, @nestjs/schedule intervals, nestjs-ioredis, nestjs-kysely pg pool, @nestjs/cache-manager Keyv store, hocuspocus pub/sub) already closes on app.close(). The two leaks were owned-but-never-closed clients: 1. ThrottleModule passed a pre-built `new Redis(...)` instance to ThrottlerStorageRedisService. With an instance, the lib sets disconnectRequired=false, so its onModuleDestroy never disconnects. Pass ioredis options instead so the service owns + disconnects the client. 2. CollaborationGateway created a source `new RedisClient(...)` that RedisSyncExtension only duplicates into pub/sub; the extension's onDestroy disconnects those duplicates but not the source. Keep a reference and disconnect it after the hocuspocus onDestroy hook in destroy(). Both are real lifecycle fixes (production shutdown is now clean too), so no --forceExit is needed. Verified against real Postgres+Redis: - test:e2e (no forceExit, --runInBand) exits 0 in ~18s (was: hung forever) - --detectOpenHandles exits 0 with no open-handle report - active handles after app.close(): none CI timeout-minutes safety nets left untouched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 04:11:51 +03:00

Author

SHA1

Message

Date

claude code agent 227

8274720281

fix(server): close leaked redis sockets so e2e jest exits (#252 )

The full-AppModule e2e (apps/server/test/app.e2e-spec.ts) passed but jest
never exited, burning CI to its timeout. Diagnosis (process._getActiveHandles
after app.close()) showed exactly two ioredis sockets to :6379 still open after
shutdown; everything else (BullMQ queues/workers, @nestjs/schedule intervals,
nestjs-ioredis, nestjs-kysely pg pool, @nestjs/cache-manager Keyv store,
hocuspocus pub/sub) already closes on app.close().

The two leaks were owned-but-never-closed clients:

1. ThrottleModule passed a pre-built `new Redis(...)` instance to
   ThrottlerStorageRedisService. With an instance, the lib sets
   disconnectRequired=false, so its onModuleDestroy never disconnects.
   Pass ioredis options instead so the service owns + disconnects the client.

2. CollaborationGateway created a source `new RedisClient(...)` that
   RedisSyncExtension only duplicates into pub/sub; the extension's onDestroy
   disconnects those duplicates but not the source. Keep a reference and
   disconnect it after the hocuspocus onDestroy hook in destroy().

Both are real lifecycle fixes (production shutdown is now clean too), so no
--forceExit is needed. Verified against real Postgres+Redis:
  - test:e2e (no forceExit, --runInBand) exits 0 in ~18s (was: hung forever)
  - --detectOpenHandles exits 0 with no open-handle report
  - active handles after app.close(): none
CI timeout-minutes safety nets left untouched.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-29 04:11:51 +03:00

fix(#252): close leftover ioredis handles so e2e jest exits cleanly (no forceExit) #254

1 Commits