Flood of ioredis error messages in @getworkbench/fastify@0.9.1

[5h0ov]

Workbench version

0.9.1

Node version

22.17.0

Reproduction

Happens every time server is started.

Downgrading to @getworkbench/fastify@0.8.0 works.

But workbench works even tho there is a flood of error messages.

Expected behavior

No flood of error messages

Actual behavior

Flood of error messages

[JacobNWolf]

Confirming this is still present on latest published packages (@getworkbench/elysia@0.9.1, which pins @getworkbench/core@0.8.0). We hit the same [ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379 flood on app startup in every environment, including ones whose queue Redis is remote ElastiCache — dashboard itself kept working.

Root cause matches #52: RedisAlertStore.createRedisClient spreads queue.opts.connection into new Redis({ ... }). When that value is a live BullMQ client instance (ioredis, and likely any non-options object), there is no url/host, so ioredis defaults to localhost:6379.

createRedisClient on main is unchanged from 0.8.0:

workbench/packages/core/src/core/redis-alert-store.ts

Lines 18 to 27 in aefd22c

	function createRedisClient(connection: string | RedisOptions): Redis {
	if (typeof connection === "string") {
	return new Redis(connection, { maxRetriesPerRequest: null });
	}
	const { url, ...rest } = connection as RedisOptions & { url?: string };
	if (url) {
	return new Redis(url, { ...rest, maxRetriesPerRequest: null });
	}
	return new Redis({ ...rest, maxRetriesPerRequest: null });
	}

Workaround that unblocks us: pass connection options into BullMQ ({ url: process.env.REDIS_URL }) instead of a shared ioredis instance, so Workbench sees a URL. Passing { url } is already honored by createRedisClient.

#52 looks like the right fix for live ioredis instances (duplicate() instead of spreading). It is still open / unmerged, so nothing on npm includes it yet. One follow-up if that lands: isRedisInstance is duck-typed as “has duplicate()”, which is also true of BullMQ’s Bun / node-redis adapters (IRedisClient). Those duplicate() results are not ioredis clients, so the alert store would still be wrong for non-ioredis queue connections unless { url } (or a real ioredis instance) is used.

[JacobNWolf]

Follow-up (same missing 'error' listener, different trigger)

#33 / #52 describe spreading a live client so ioredis dials 127.0.0.1:6379 (ECONNREFUSED). We still hit a flood when Workbench does get a correct { url } (remote ElastiCache / rediss://…).

RedisAlertStore.createRedisClient still does new Redis(url) with no 'error' listener. ioredis then console.errors every peer drop:

[ioredis] Unhandled error event: Error: write EPIPE
[ioredis] Unhandled error event: Error: read ECONNRESET

That showed up loudly on Bun 1.4 because node:net now reports those socket errors the way Node does; the adapter gap is the same. Dashboard keeps working; only the alert-store connection is noisy.

#52 already adds that listener (warn once, retry quietly). That would cover this path too. Until it ships, we used alerts: { persistence: 'memory' } so the extra ioredis client is not created.

Seen with @getworkbench/elysia@0.9.1 / @getworkbench/core@0.8.0.