v3.0.2

Patch release — fixes a failure mode that could silently stop all notification handling on a channel.

Fixes

• A channel could end up with no listener at all, permanently, after a lock takeover (#28).

  In the default single-listener mode, only one process holds a channel's lock and issues LISTEN; the others retry on a timer. Acquiring the lock is only half the job — the LISTEN happens right after acquire() returns true. When a process lost the initial race and its retry timer later won the lock (after the previous holder went away), that second half never ran: the original caller was long gone. The process then sat holding the lock and doing nothing with it — and because it held the lock, every other process was kept away too. Net effect: notifications on that channel stopped being handled by anyone, and stayed that way.

  Locks now expose an onAcquire handler that fires on a late, timer-driven takeover, so the winner completes the subscription it was queued up for.

Notes for integrators

• AnyLock gained a required onAcquire(handler) method. If you have a custom lock implementation, it needs one — NoLock implements it as a no-op, since a lock that is never contended is never taken over late.

About

@imqueue/pg-pubsub provides reliable PostgreSQL LISTEN/NOTIFY with inter-process lock support: a single logical subscriber across many processes, so a notification is handled once per cluster rather than once per process, with automatic reconnection. It is usable independently of the rest of @imqueue.

• Docs: https://imqueue.org/
• Guide for AI assistants / LLMs: https://imqueue.org/llms.txt
• Commercial license & support: https://imqueue.com/
• npm i @imqueue/pg-pubsub