From bff79e3e5ff49884c56218de5e7308eff2aa4682 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 18 Sep 2026 00:20:32 +0000 Subject: [PATCH] docs(changelog): correct the falsified batch-cap claim in the published 17.0.0 and 17.0.0-rc.1 entries A dedicated docs-only PR, which AGENTS.md's Documentation Guardrails row for `packages/*/CHANGELOG.md` requires: a factual error in a released entry is amended in that entry, never as an erratum in a later one and never as a rider on code changes. This diff is exactly two files, adds no source, no schema, no export and no changeset. The 2026-09-07 ruling found that no reader of a published surface can configure `batch.maxBatchSize`. The `789ad63` entry carries that falsified claim in two wordings, and the copy under `## 17.0.0` and the copy under `## 17.0.0-rc.1` are both published text, so all four copies are corrected: - "Batch size is deployment policy" -> "embedder policy", and the counterfactual beside it ("a deployment raising the limit to 500") now reads "a host". - The behaviour bullet stopped issuing an instruction no shipped boot path can carry out. It read "Deployments ... should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in production"; it now states where the cap actually comes from. One dated erratum line closes each entry, carrying the in-repo tail this repository already uses, and quoting both published wordings verbatim so the record of what shipped is still readable. The 1..1000 range, the 200 default and the enforcement this release shipped are unchanged. Vocabulary is copied from the four prior landings of this same correction rather than invented. Claude-Session: https://claude.ai/code/session_017ef78bLdybu3AffehKkhfk Co-authored-by: Claude --- packages/rest/CHANGELOG.md | 26 ++++++++++++++++---------- packages/spec/CHANGELOG.md | 26 ++++++++++++++++---------- 2 files changed, 32 insertions(+), 20 deletions(-) diff --git a/packages/rest/CHANGELOG.md b/packages/rest/CHANGELOG.md index 46c756f4265..5358eec3d37 100644 --- a/packages/rest/CHANGELOG.md +++ b/packages/rest/CHANGELOG.md @@ -5262,9 +5262,9 @@ export`) are DERIVED from the primitives, never declared standalone. (This request, where before it was one statement that mostly failed anyway. **The cap moved to the routes, and the schemas gave it up.** Batch size is - deployment policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200 + embedder policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200 — so a hardcoded bound in the spec could only ever be a second, wrong answer - (a deployment raising the limit to 500 would still have been refused at 200). + (a host raising the limit to 500 would still have been refused at 200). All five bulk routes now call one `enforceBatchSize` helper with the configured value and answer with one envelope: @@ -5300,9 +5300,10 @@ export`) are DERIVED from the primitives, never declared standalone. (This **Behaviour changes.** - A bulk request over the configured cap is `400 BATCH_TOO_LARGE` instead of - being executed. Deployments that were quietly relying on unbounded batches - should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in - production. + being executed. A deployment that was quietly relying on unbounded batches + meets the cap at whatever value the host embedding the server passed for + `batch.maxBatchSize` — 200 unless it passed one, which no shipped boot path + does. - `.min(1)` is gone with `.max(200)`: an empty batch is a no-op returning `total: 0`, which is what these routes already did, rather than a validation error the schema claimed but nothing raised. @@ -5312,6 +5313,8 @@ export`) are DERIVED from the primitives, never declared standalone. (This type was looser. - New export: `UpdateManyRecordSchema` / `UpdateManyRecord`. + *Erratum, 2026-09-18 — this entry called the batch cap "deployment policy" and told operators that deployments relying on unbounded batches "should raise `batch.maxBatchSize` (up to 1000)". The cap is embedder policy: `RestServerConfig.batch.maxBatchSize` is the argument a host passes when it constructs the server, and neither shipped boot path passes it — `os serve` forwards exactly two keys out of the stack config's `api:` block (`api.enableProjectScoping`, `api.projectResolution`) and the dev plugin calls `createRestApiPlugin()` with no config at all — so a CLI-started deployment always gets the 200 default and no flag, config file or CLI option moves it. Two passages above are corrected in place; the 1..1000 range, the 200 default and the enforcement this release shipped are unchanged. (Corrected after publication, #18740.)* + - fccec22: fix(rest): bulk writes bind to the object in the path, not the one in the body (#3933) `POST /data/:object/updateMany` spread the request body over the value it had @@ -15189,9 +15192,9 @@ IEmailService`, `ExternalDatasourceService implements IExternalDatasourceService request, where before it was one statement that mostly failed anyway. **The cap moved to the routes, and the schemas gave it up.** Batch size is - deployment policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200 + embedder policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200 — so a hardcoded bound in the spec could only ever be a second, wrong answer - (a deployment raising the limit to 500 would still have been refused at 200). + (a host raising the limit to 500 would still have been refused at 200). All five bulk routes now call one `enforceBatchSize` helper with the configured value and answer with one envelope: @@ -15227,9 +15230,10 @@ IEmailService`, `ExternalDatasourceService implements IExternalDatasourceService **Behaviour changes.** - A bulk request over the configured cap is `400 BATCH_TOO_LARGE` instead of - being executed. Deployments that were quietly relying on unbounded batches - should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in - production. + being executed. A deployment that was quietly relying on unbounded batches + meets the cap at whatever value the host embedding the server passed for + `batch.maxBatchSize` — 200 unless it passed one, which no shipped boot path + does. - `.min(1)` is gone with `.max(200)`: an empty batch is a no-op returning `total: 0`, which is what these routes already did, rather than a validation error the schema claimed but nothing raised. @@ -15239,6 +15243,8 @@ IEmailService`, `ExternalDatasourceService implements IExternalDatasourceService type was looser. - New export: `UpdateManyRecordSchema` / `UpdateManyRecord`. + *Erratum, 2026-09-18 — this entry called the batch cap "deployment policy" and told operators that deployments relying on unbounded batches "should raise `batch.maxBatchSize` (up to 1000)". The cap is embedder policy: `RestServerConfig.batch.maxBatchSize` is the argument a host passes when it constructs the server, and neither shipped boot path passes it — `os serve` forwards exactly two keys out of the stack config's `api:` block (`api.enableProjectScoping`, `api.projectResolution`) and the dev plugin calls `createRestApiPlugin()` with no config at all — so a CLI-started deployment always gets the 200 default and no flag, config file or CLI option moves it. Two passages above are corrected in place; the 1..1000 range, the 200 default and the enforcement this release shipped are unchanged. (Corrected after publication, #18740.)* + - fccec22: fix(rest): bulk writes bind to the object in the path, not the one in the body (#3933) `POST /data/:object/updateMany` spread the request body over the value it had diff --git a/packages/spec/CHANGELOG.md b/packages/spec/CHANGELOG.md index 4d7797e5ef2..48ebd2808d4 100644 --- a/packages/spec/CHANGELOG.md +++ b/packages/spec/CHANGELOG.md @@ -27471,9 +27471,9 @@ object:'task', function:'count', filter:{ status:'completed' } } }` lost that request, where before it was one statement that mostly failed anyway. **The cap moved to the routes, and the schemas gave it up.** Batch size is - deployment policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200 + embedder policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200 — so a hardcoded bound in the spec could only ever be a second, wrong answer - (a deployment raising the limit to 500 would still have been refused at 200). + (a host raising the limit to 500 would still have been refused at 200). All five bulk routes now call one `enforceBatchSize` helper with the configured value and answer with one envelope: @@ -27509,9 +27509,10 @@ object:'task', function:'count', filter:{ status:'completed' } } }` lost that **Behaviour changes.** - A bulk request over the configured cap is `400 BATCH_TOO_LARGE` instead of - being executed. Deployments that were quietly relying on unbounded batches - should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in - production. + being executed. A deployment that was quietly relying on unbounded batches + meets the cap at whatever value the host embedding the server passed for + `batch.maxBatchSize` — 200 unless it passed one, which no shipped boot path + does. - `.min(1)` is gone with `.max(200)`: an empty batch is a no-op returning `total: 0`, which is what these routes already did, rather than a validation error the schema claimed but nothing raised. @@ -27521,6 +27522,8 @@ object:'task', function:'count', filter:{ status:'completed' } } }` lost that type was looser. - New export: `UpdateManyRecordSchema` / `UpdateManyRecord`. + *Erratum, 2026-09-18 — this entry called the batch cap "deployment policy" and told operators that deployments relying on unbounded batches "should raise `batch.maxBatchSize` (up to 1000)". The cap is embedder policy: `RestServerConfig.batch.maxBatchSize` is the argument a host passes when it constructs the server, and neither shipped boot path passes it — `os serve` forwards exactly two keys out of the stack config's `api:` block (`api.enableProjectScoping`, `api.projectResolution`) and the dev plugin calls `createRestApiPlugin()` with no config at all — so a CLI-started deployment always gets the 200 default and no flag, config file or CLI option moves it. Two passages above are corrected in place; the 1..1000 range, the 200 default and the enforcement this release shipped are unchanged. (Corrected after publication, #18740.)* + - f2445c9: feat(spec,objectql,client,plugin-webhooks): predicate writes get an honest bulk event contract (#4639) A `multi: true` update/delete reaches `IDataDriver.updateMany` / `deleteMany`, @@ -69646,9 +69649,9 @@ schedule }`), not on the flow. request, where before it was one statement that mostly failed anyway. **The cap moved to the routes, and the schemas gave it up.** Batch size is - deployment policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200 + embedder policy — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200 — so a hardcoded bound in the spec could only ever be a second, wrong answer - (a deployment raising the limit to 500 would still have been refused at 200). + (a host raising the limit to 500 would still have been refused at 200). All five bulk routes now call one `enforceBatchSize` helper with the configured value and answer with one envelope: @@ -69684,9 +69687,10 @@ schedule }`), not on the flow. **Behaviour changes.** - A bulk request over the configured cap is `400 BATCH_TOO_LARGE` instead of - being executed. Deployments that were quietly relying on unbounded batches - should raise `batch.maxBatchSize` (up to 1000) rather than discover the cap in - production. + being executed. A deployment that was quietly relying on unbounded batches + meets the cap at whatever value the host embedding the server passed for + `batch.maxBatchSize` — 200 unless it passed one, which no shipped boot path + does. - `.min(1)` is gone with `.max(200)`: an empty batch is a no-op returning `total: 0`, which is what these routes already did, rather than a validation error the schema claimed but nothing raised. @@ -69696,6 +69700,8 @@ schedule }`), not on the flow. type was looser. - New export: `UpdateManyRecordSchema` / `UpdateManyRecord`. + *Erratum, 2026-09-18 — this entry called the batch cap "deployment policy" and told operators that deployments relying on unbounded batches "should raise `batch.maxBatchSize` (up to 1000)". The cap is embedder policy: `RestServerConfig.batch.maxBatchSize` is the argument a host passes when it constructs the server, and neither shipped boot path passes it — `os serve` forwards exactly two keys out of the stack config's `api:` block (`api.enableProjectScoping`, `api.projectResolution`) and the dev plugin calls `createRestApiPlugin()` with no config at all — so a CLI-started deployment always gets the 200 default and no flag, config file or CLI option moves it. Two passages above are corrected in place; the 1..1000 range, the 200 default and the enforcement this release shipped are unchanged. (Corrected after publication, #18740.)* + - 2af1988: fix(formula,spec,core): the RLS write-side `check` evaluator honours calendar-day upper bounds (ADR-0053 D-D) `@objectstack/formula`'s `matchesFilterCondition` — the evaluator behind RLS