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

Đang mở
  • Có gì không ổn?
#5,452 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@vishalrajofficial đang làm issue này rồi.

Từ ngày 15/11/2026.

  • #5453 của @vishalrajofficial — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
Nửa ngày
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
nodejs, postgresql, typescript
Lĩnh vực
authentication, backend, databases

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
2.5k
Fork
401
Merge trung bình
2 ngày 36 phút
Pull request đã merge (30 ngày)
150

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của vercel/workflow

Tất cả issue của vercel/workflow

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.