Potential timeout-handle retention in `PostgresMessageQueue.listen()` under delayed retries

[dahlia]

Summary

While investigating gradual worker heap growth, I found a potential memory retention issue in PostgresMessageQueue.listen() under delayed retry traffic.

Why this may matter

If delayed messages are frequent, retained timeout handles can accumulate in memory and contribute to gradual heap growth in long-running workers.

Suspected code path

In packages/postgres/src/mq.ts, delayed notifications call timeouts.add(setTimeout(serializedPoll, durationMs)), but the handle is not removed from timeouts after the callback runs.

const timeouts = new Set<ReturnType<typeof setTimeout>>();

const listen = await this.#sql.listen(
  this.#channelName,
  async (delay) => {
    const durationMs = Temporal.Duration.from(delay).total("millisecond");
    if (durationMs < 1) await serializedPoll();
    else timeouts.add(setTimeout(serializedPoll, durationMs));
  },
  serializedPoll,
);

signal?.addEventListener("abort", () => {
  listen.unlisten();
  for (const timeout of timeouts) clearTimeout(timeout);
});

Expected behavior

Executed timeout handles should be removed from the tracking set so the set size does not grow monotonically during normal operation.

Suggested fix

Delete each handle when it fires and optionally clear the set during abort cleanup.

const timeout = setTimeout(() => {
  timeouts.delete(timeout);
  void serializedPoll();
}, durationMs);
timeouts.add(timeout);

Additional context

This was observed while investigating production-like worker memory growth in fedify-dev/hollo#365, so that issue is a related report rather than direct proof of root cause.

[dahlia]

Reproduction profile

• Runtime: Node.js 22.x
• Queue backend: PostgresMessageQueue
• Process type: long-lived federation worker
• Traffic pattern: frequent delivery failures that trigger delayed retries
• Delay path exercised: retry enqueue with delay > 0 in outbox/inbox retry flow
• Synthetic delay range used during reproduction: 100–500 ms

Reproduction steps

1. Start a worker using PostgresMessageQueue.
2. Continuously enqueue delayed messages for 30–60 min and ensure timer callbacks actually execute.
3. Keep delayed traffic sustained so the delayed-notification path stays hot.
4. Monitor process heap and retained objects over time.

Observed behavior

• Heap usage trends upward gradually instead of reaching a stable plateau.
• The pattern is slow accumulation over time, not an immediate spike.
• Retainer patterns are consistent with timeout handles remaining referenced longer than expected.

Optional quick instrumentation

let lastLog = 0;

// inside listen()
if (Date.now() - lastLog > 10_000) {
  logger.info("timeouts.size={size}", { size: timeouts.size });
  lastLog = Date.now();
}

Expected behavior

timeouts.size should represent only active timers and should return toward baseline as fired timers are cleaned up.