pipework 0.205.0 → 0.207.0

package/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Changelog
 
+## 0.207.0
+
+- **Fixed: queue ops threw on a fitting's tenant-scoped handle** (#786). `enqueue`, `enqueueAndWait`, `cancel`, `retryNow`, `flowOf`, `waitFor`, `requeueDeadLetter` and `totals` now run on the handle a fitting gets from `.use('app')` or `pipe()` under a tenant, on the caller's transaction, confined to that tenant's jobs (`flow_tenant`): another tenant's job behaves as a missing one, and enqueuing for another tenant throws. The worker and schedule ops (`claim`, `heartbeat`, `complete`, `fail`, `failAttempt`, `later`, `handBack`, `reap`, `schedule`, `syncSchedules`, `fireSchedule`, `runDueSchedules`, `unschedule`, `listSchedules`, `startScheduler`) act across tenants and now refuse a scoped handle up front, naming the unscoped handle to pass. The same holds across APIs that take a `DB`: `pipe.advisoryLock`, `pipe.tryAdvisoryLock` and `pipe.withTimeouts` run on a scoped handle; `pipe.bulkSet`, webhook `send` / `registerEndpoint` / `listEndpoints` / `removeEndpoint`, idempotency `find` / `lock` / `complete` / `remove`, `mail.send` and step graphs run confined to its tenant; webhook `deliver` / `processPending`, idempotency `cleanup`, `mail.sentTo`, `sessions`, `emailLinks`, `multiOrg` and pipelines refuse it with that error instead of the generic `execute()` one. `.execute()` on a scoped handle still throws, and unscoped handles behave as before.
+
+## 0.206.0
+
+- **Fixed: `insert(T).values(list)` on a DB handle or its `tx` failed past Postgres's parameter limit** (#783, #784). A handle from `tap()`, `pool.getOrCreate().drizzle` or the test fixture, and the `tx` of its `.transaction(...)` (nested too), now splits a list over the limit into several statements the way `pipe.insert` does, with `onConflictDoNothing`, `onConflictDoUpdate` and `returning` applied to each. They run on that handle, so they commit and roll back with the caller's transaction (a savepoint when it is already one). A list under the limit is drizzle's own builder, unchanged. `toSQL()`, `prepare()` and `$dynamic()` of an over-limit list throw. `pipe.insert` inside a `db.transaction` callback still does not join that `tx`; use the `tx`'s own `insert`.
+
 ## 0.205.0
 
 - **Fixed: a PDF with bytes before `%PDF-` was refused as not a PDF** (#781). Byte detection now names a file `application/pdf` when `%PDF-` starts anywhere in its first 1024 bytes, as PDF readers do, so an upload with a leading CRLF, BOM or mail header passes `mediaTypes: ['application/pdf']`. The search runs only when no other signature matches, so a zip or PNG that contains `%PDF-` keeps its type, and every other signature is still read from the first 512 bytes. **Behavior change:** `SNIFF_BYTES` is now 1024, so `.upload()` and inbound email attachments hold the first 1024 bytes of a file to detect its type.

package/REFERENCE.md

@@ -994,6 +994,8 @@ interface ManagedConnection
 
 **`ConnectOptions`** — Options for `tap()` — pool size (default 1), idle timeout in seconds, and `settings` (see below).
 
+**Large inserts on a handle** — `insert(T).values(list)` on a `tap()` or `pool.getOrCreate().drizzle` handle, and on the `tx` of its `.transaction(...)` (nested too), splits a list over Postgres's parameter limit into several statements the way `pipe.insert` does, with `onConflictDoNothing`, `onConflictDoUpdate` and `returning` applied to each. They run on that handle, so they stay in the caller's transaction (a savepoint when it is already one), and a throw later in the callback rolls them all back. `toSQL()` and `prepare()` of an over-limit list throw.
+
 **Session settings (`databases.<name>.pool.settings`, `tap({ settings })`)** — `Record<string, string | number | boolean>`, default none. Each entry is a Postgres session setting (GUC) sent in the connection's startup packet, so every pooled socket carries it from its first packet, including a connection the pool replaced at `max_lifetime` or after a backend was terminated. A session `SET` on a pooled connection does not survive replacement; use `settings` for anything that must hold for the life of the pool. Names are `name` or `prefix.name` (letters, digits, underscores); anything else is a config error. Values are stringified (`true` is `on`, `false` is `off`). A dotted custom name (`myapp.tenant`) is always accepted. An unknown non-dotted name is rejected by Postgres: the connection fails, and the first query on the pool rejects, and the error's `cause` is Postgres's own (`unrecognized configuration parameter "..."`); pipework does not translate it.
 
 ```typescript