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