chore(deps)(deps): Bump @nest-native/messaging from 0.3.1 to 0.5.0

[dependabot]

Bumps @nest-native/messaging from 0.3.1 to 0.5.0.

Changelog

Sourced from @​nest-native/messaging's changelog.

0.5.0 - 2026-07-19

• Added the cross-machine wake for the Postgres dialect — LISTEN/NOTIFY. Completes the wake tiers from 0.4.0: new PostgresOutboxStore({ wakeChannel }) piggybacks pg_notify on the enqueue transaction (Postgres delivers it on commit and drops it on rollback, so the wake is atomic with the event becoming visible — no post-commit discipline needed), and the new PostgresWakeListener (at @nest-native/messaging/postgres) holds a dedicated LISTEN connection that feeds the worker's OutboxWaker, reconnecting with a fixed delay when the connection drops. Best-effort by the same contract as the other tiers: notifications missed during a reconnect gap are not recovered — polling remains the delivery backstop, so a lost wake only costs one poll interval, never an event. Channels are allow-listed to an identifier-safe charset (LISTEN cannot be parameterized), capped at Postgres's 63-byte identifier limit (beyond it LISTEN silently truncates while pg_notify RAISES — which would abort the caller's business transaction), and double-quoted, keeping LISTEN case-sensitivity aligned with pg_notify's exact-string channel. The listener survives the pg end-during-connect edge (a client ended mid-connect never settles its connect() promise — the session races it against the connection's own end/error events so stop() cannot hang), guards a throwing custom WakeSignal from crashing the worker, validates reconnectDelayMs, and the documented factory sets keepAlive: true so a half-open LISTEN socket is detected by the OS. Postgres-only by nature; SQLite/MySQL use the WakeSocket tier. Verified against real Postgres: delivered on commit, dropped on rollback.

0.4.0 - 2026-07-19

• Added OutboxWaker — an in-process wake for the worker loop. The worker only waits pollIntervalMs when a tick claims nothing, so that interval is the worst-case latency for a lone event landing in an idle outbox. Pass an OutboxWaker to runWorkerLoop({ waker }) and call waker.notify() after the enqueueing transaction commits to cut that idle wait short — the worker relays immediately instead of on the next poll. Polling stays the backstop, so a missed or absent notify() never stalls delivery (it only widens latency back to one interval), and wakes are latched so an event committed in the sliver between a tick and its sleep is never lost. Same-process only; a cross-process wake (Postgres LISTEN/NOTIFY) is a planned follow-up. Opt-in and fully backward compatible — omit the waker and the loop is an unchanged pure poller.
• Added WakeSocketServer / WakeSocketClient — the cross-process wake for processes on the same machine (the classic app + start:worker split sharing one database, where an in-memory notify() can't cross the boundary). The worker listens on a unix domain socket (Windows: a \\.\pipe\… name) and feeds incoming connections into its OutboxWaker; producers hold a WakeSocketClient on the same path and notify() after the enqueueing transaction commits — fire-and-forget, never throwing into the request path. Built on node:net alone (zero new dependencies, dialect-agnostic; for the SQLite store this covers every supported deployment, since processes sharing a SQLite file are on one machine by definition). The server recovers a stale

... (truncated)

Commits

• 7dd8282 chore(release): 0.5.0 (#24)
• ac90566 feat: add the cross-machine wake for Postgres — LISTEN/NOTIFY (#23)
• f4af54c chore(release): 0.4.0 (#22)
• 2344fe6 feat: add WakeSocketServer/WakeSocketClient — cross-process wake (same machin...
• 44e4c79 feat: add OutboxWaker — in-process wake to cut worker idle latency (#20)
• 41e45ba chore(deps)(deps): bump the messaging-peer-minor-patch group across 1 directo...
• 9a517fa test: kill mutation survivors in @​nest-native/messaging (#11)
• 226c578 chore: local full-mode verification + Stryker mutation testing (opt-in, never...
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)