world-postgres: LISTEN clients lose non-enumerable pg password credentials

Aperta
  • Qualcosa non va?
#5,452 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@vishalrajofficial ci sta già lavorando.

Dal 15/11/2026.

  • #5453 di @vishalrajofficial — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
nodejs, postgresql, typescript
Ambito
authentication, backend, databases

Direzione di ricerca

Start with listenChannel in packages/world-postgres/src/streamer.ts, where the reconnect path builds its config with { ...pool.options, connectionTimeoutMillis }, and with the same spread in packages/world-postgres/src/invocation-notifications.ts. Confirm that pool.options.password is non-enumerable in pg, then check that replacement clients keep the password callback after a reconnect. Pull request #5453 is already open against this issue, so review or test that fix rather than starting a parallel one.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

The dedicated PostgreSQL notification clients lose authentication credentials when they copy pool.options with object spread. pg.Pool deliberately makes options.password non-enumerable, so the copy omits both static passwords and async password callbacks.

Two paths are affected:

  1. listenChannel in streamer.ts: the initial subscription receives pool.options directly and succeeds, but reconnect adds connectionTimeoutMillis through { ...pool.options, connectionTimeoutMillis }. After a connection drop, replacement clients cannot authenticate. The loop retries without restoring the listener.
  2. createInvocationNotifications in invocation-notifications.ts: the same spread happens on every subscription, including the first. Authenticated configurations using password can remain on fallback reads from startup.

Ordinary pooled queries can continue working while notifications fail. Existing live stream readers may stop seeing newly persisted chunks; a fresh read can see the data. This particularly affects token-based database authentication, where the password must remain a callback invoked for each new connection.

Versions checked

  • Reproduced against @workflow/world-postgres 5.1.1, Node 24.22.2, a supplied pool from pg 8.23.1, and the package's own pg 8.20.0 client.
  • Real-database validation used PostgreSQL 17.
  • Inspected 5.2.0: the stream reconnect path still uses the credential-dropping spread.
  • Both paths remain in the source at b1f92691bcc3bc18b9df094d45379c6464cf4d65.

Minimal reproduction of the credential loss

This requires only pg and does not open a connection:

import assert from 'node:assert/strict';
import { Pool } from 'pg';

const password = async () => 'example-token';
const pool = new Pool({ password, connectionTimeoutMillis: 15000 });
const reconnectConfig = {
  ...pool.options,
  connectionTimeoutMillis: 15000,
};

assert.equal(pool.options.password, password);
assert.equal(
  Object.getOwnPropertyDescriptor(pool.options, 'password').enumerable,
  false,
);
assert.equal(reconnectConfig.password, undefined);

console.log({
  originalPasswordType: typeof pool.options.password, // 'function'
  copiedPasswordType: typeof reconnectConfig.password, // 'undefined'
});
await pool.end();

A real listener reproduction follows the same failure path:

  1. Use a password-authenticated PostgreSQL instance and pass an injected Pool with separate host/user/database fields and password: async () => currentPassword. Do not embed the password in connectionString, or supply PGPASSWORD, since those can mask the omission.
  2. Open listenChannel(pool, 'workflow_event_chunk', onPayload, { onReconnect }) from the built streamer.js; verify an initial notification is delivered.
  3. From a separate administrative connection, terminate only that listener backend using pg_terminate_backend.
  4. Its reconnect creates a client without the password callback. onReconnect never fires and new notifications are not delivered, although pooled reads still work.
  5. For the invocation notifier, subscribing a watch is sufficient to expose the failure: its initial dedicated client is already missing the callback.

Expected behavior and proposed correction

Every dedicated client should preserve the pool's authentication configuration, including the live password callback, while applying its existing timeout and application-name overrides. Do not resolve the callback once and cache the resulting token.

A local correction that preserves non-enumerability is:

const config = Object.defineProperties(
  {},
  Object.getOwnPropertyDescriptors(pool.options),
);
if (connectionTimeoutMillis) {
  config.connectionTimeoutMillis = connectionTimeoutMillis;
}
const client = new Client(config);

Apply equivalent copying before the invocation notifier's overrides.

Validation

Regression tests against the installed listener implementations and real pg.Pool/pg.Client constructors fail before correction and pass after it:

  • Stream reconnect retains a static password.
  • Stream reconnect invokes the dynamic password callback again after token rotation and resumes notifications.
  • Invocation notification subscription authenticates initially and after a disconnect.

The network methods are stubbed in those unit regressions. A separate real PostgreSQL probe also terminated the listener backends, changed the database user's password, verified that replacement clients obtained the new password through the callback, and confirmed notification delivery resumed for both paths after the correction.

Related: #4630 concerns surviving a listener disconnect and re-subscribing. This report concerns credentials being lost by the options copy in those subscription paths.

Lingua principale
TypeScript
Stelle
2.5k
Fork
401
Merge medio
2g 36m
PR unite (30g)
150

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di vercel/workflow

Tutte le issue di vercel/workflow

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.