Skip to content

Commit 5ccfc2e

Browse files
claudeclaude
committed
fix(rest,service-settings,service-datasource)!: four more route modules emit the declared envelope, and the guard is shared (#3843)
#3675 and #3689 moved service-storage and service-i18n onto BaseResponseSchema. Each scoped itself to one service, and neither asked whether the same drift existed elsewhere. It did — in four more modules, two of them carrying the *older* shape #3675 had already declared wrong: settings-routes.ts nested error, no `success` on any of 5 bodies admin-routes.ts { error: '<string>' }, `message` a SIBLING external-datasource-routes.ts { error: '<string>' } + a private `ok` package-routes.ts 3 of 16 bodies had the flag; 2 failures had no `error` at all All four now build every body through a sendOk / sendError pair. Success payloads keep their keys and move under `data`; error bodies become { success: false, error: { code, message } }, so `body.error.message` finally reads the service's message instead of `undefined` — the asymmetry #3675 opened on. Codes are CARRIED OVER, not renamed: admin-routes and external-datasource-routes keep their lowercase snake codes so #3841 can pick one vocabulary for all ~240 at once. Only package-routes needed minted codes, because its `error` strings were human messages with no code to carry. POST /external/validate keeps its `ok`: unlike the `{ ok: true, key }` #3689 retired, that one is a computed verdict over the federated objects, and the request can succeed while the verdict is false. The guard is shared now, not copied. New private @objectstack/route-envelope-conformance exports one pure checkRouteEnvelope(source) => finding[]. Its load-bearing assertion is structural rather than per-route — it COUNTS the `.json(` call sites, which stays fixed at the number of builders no matter how many routes exist, so a future route that hand-rolls a body fails the guard. That is coverage a driven test cannot give. The scan existed three times as an open-coded regex block; all three now delegate to it, as do the four new per-module suites. The shared version also fixes a real bug in those copies: they stripped comments with String.replace, which also ate `//` inside string literals and truncated the rest of that line, `.json(` calls included. A guard that under-counts call sites passes while drift ships. The shared scanner tokenizes and pins that case in its own suite. One ratchet, stated rather than hidden: i18n-service-plugin.ts is declared at jsonCallSites: 5, successBuilders: 4. Its error half is consolidated, but its four read routes build correct envelopes inline. Those numbers pin today's structure (a new inline body fails) and drop to 2/1 on consolidation. Consumers were taught both shapes first so the repos are not coupled by merge order — objectui's packages readers were already tolerant; its datasource page and the generic `type: 'api'` action runner now unwrap the envelope and read error.message (the latter previously toasted "[object Object]"). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CYbS3kS8xzsHNXFTzp4e2z
1 parent e2c64f1 commit 5ccfc2e

28 files changed

Lines changed: 2487 additions & 119 deletions

‎.changeset/route-envelope-four-more-modules.md‎

Lines changed: 107 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,107 @@
1+
---
2+
"@objectstack/rest": patch
3+
"@objectstack/service-settings": patch
4+
"@objectstack/service-datasource": patch
5+
---
6+
7+
fix(rest,service-settings,service-datasource)!: four more route modules emit the declared envelope, and the guard is now shared (#3843)
8+
9+
#3675 and #3689 moved `service-storage` and `service-i18n` onto the declared
10+
response envelope (`BaseResponseSchema` + `ApiErrorSchema`). Each scoped itself
11+
to one service, and neither asked whether the same drift existed elsewhere. It
12+
did — in four more modules, and in two of them it was the *older* shape, the one
13+
#3675 had already declared wrong:
14+
15+
| Module | before | now |
16+
|---|---|---|
17+
| `service-settings/settings-routes.ts` | nested `error`, no `success` on any of 5 bodies | full envelope |
18+
| `service-datasource/admin-routes.ts` | `{ error: '<string>' }`, `message` a **sibling** | full envelope |
19+
| `rest/external-datasource-routes.ts` | `{ error: '<string>' }` + a private `ok` | full envelope |
20+
| `rest/package-routes.ts` | 3 of 16 bodies had `success`, 2 failures had no `error` at all | full envelope |
21+
22+
## Breaking: where to read things now
23+
24+
**Success payloads move under `data`.** The keys are unchanged — only their
25+
depth. `unwrapResponse` in `ObjectStackClient` returns `body.data` when the flag
26+
is present, so every SDK method (`packages.list()`, `datasources.external.*`)
27+
resolves to exactly the object it always did. Raw `fetch` callers must add one
28+
hop:
29+
30+
```
31+
GET /api/v1/datasources body.datasources → body.data.datasources
32+
GET /api/v1/datasources/drivers body.drivers → body.data.drivers
33+
GET /api/v1/datasources/:name body.datasource → body.data.datasource
34+
GET /api/v1/packages body.packages → body.data.packages
35+
GET /api/v1/packages/:id body.package → body.data.package
36+
GET /api/settings body.manifests → body.data.manifests
37+
GET /api/settings/:ns body.manifest/.values → body.data.manifest/.values
38+
POST /…/external/validate body.ok, body.results → body.data.ok, body.data.results
39+
```
40+
41+
`SettingsNamespacePayloadSchema` and friends still describe those payloads
42+
exactly; they now describe the envelope's `data` rather than the whole body.
43+
44+
**Error bodies stop being a string.** `{ error: 'datasource_admin_error',
45+
message }` → `{ success: false, error: { code: 'datasource_admin_error',
46+
message } }`. Read `body.error.message`, not `body.message`; read
47+
`body.error.code`, not `body.error`. This is the asymmetry #3675 opened on: a
48+
caller reading `body.error.message` previously got the real message from the
49+
dispatcher and `undefined` from these routes.
50+
51+
**Two failures that never said why now do.** `DELETE /api/v1/packages/:id`
52+
answered a bare `{ success: false }` and a bare
53+
`{ success: false, failed, cleanups }`. They are now `PACKAGE_DELETE_FAILED` and
54+
`PACKAGE_DELETE_PARTIAL`, with the per-item `failed` / `cleanups` arrays under
55+
`error.details`.
56+
57+
**Codes: carried over, not renamed.** `admin-routes.ts` and
58+
`external-datasource-routes.ts` keep their existing lowercase snake codes
59+
(`datasource_admin_unavailable`, `external_service_unavailable`, `not_found`, …)
60+
even though they sit beside SCREAMING_SNAKE in the already-converted siblings.
61+
Which vocabulary wins is #3841's call — a decision about ~240 codes repo-wide —
62+
and re-spelling nine of them here would pick that dialect by accident. Only
63+
`package-routes.ts` needed *minted* codes, because its `error` strings were human
64+
messages with no code to carry; those follow the SCREAMING_SNAKE the two
65+
converted siblings emit and #3841 will re-spell them with everything else. This
66+
is the envelope only, the same split #3687 / #3837 made deliberately.
67+
68+
**`POST /external/validate` keeps its `ok`.** Unlike the `{ ok: true, key }`
69+
#3689 retired from storage — a private second word for `success` — this `ok` is a
70+
computed verdict over the federated objects (`results.every(r => r.ok)`). The
71+
request can succeed while the verdict is false, so the two flags are not the same
72+
field; `ok` moves inside `data` rather than being dropped.
73+
74+
Consumers were taught both shapes first, so the two repos are not coupled by
75+
merge order: objectui's `packages` readers were already tolerant
76+
(`payload?.data ?? payload`), and its datasource page plus the generic
77+
`type: 'api'` action runner now unwrap the envelope and read `error.message`
78+
(the latter previously toasted `[object Object]` for any nested error).
79+
80+
## The guard is shared now, not copied
81+
82+
New private `@objectstack/route-envelope-conformance` (`packages/qa/route-envelope`)
83+
exports one pure `checkRouteEnvelope(source) => finding[]`. Its load-bearing
84+
assertion is structural rather than per-route: **count the `.json(` call sites**.
85+
When every body goes through the `sendOk` / `sendError` pair, that count is fixed
86+
at two and does not grow with the route list — so a *future* route that
87+
hand-rolls a body fails the guard, which is the coverage a driven test can never
88+
give.
89+
90+
This existed three times already as an open-coded regex block (storage error,
91+
storage success, i18n error); the third copy was the signal it wanted lifting
92+
(#3843 option 3, done before the conversions). All three now delegate to it, as
93+
do the four new per-module suites. The shared version also fixes a real bug in
94+
the copies: they stripped comments with `String.replace`, which also ate `//`
95+
inside string literals and silently truncated the rest of that line —
96+
`.json(` calls included. A guard that under-counts call sites passes while drift
97+
ships, which is the failure mode this issue is about. The shared scanner
98+
tokenizes properly and pins that case in its own suite.
99+
100+
**One ratchet, stated rather than hidden.** `i18n-service-plugin.ts` is declared
101+
at `jsonCallSites: 5, successBuilders: 4`. Its error half *is* consolidated
102+
(#3675), but each of its four read routes builds `{ success: true, data }`
103+
inline. Those bodies are correct — that is not envelope drift — but an
104+
unconsolidated builder is a weaker guard: a fifth read route could get the shape
105+
wrong and only a driven test would notice. The numbers pin today's structure
106+
exactly (a new inline body fails), and consolidating behind a `sendOk` drives
107+
them to the 2 / 1 the other five modules use.

‎packages/qa/route-envelope/LICENSE‎

Lines changed: 202 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,202 @@
1+
Apache License
2+
Version 2.0, January 2004
3+
http://www.apache.org/licenses/
4+
5+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
6+
7+
1. Definitions.
8+
9+
"License" shall mean the terms and conditions for use, reproduction,
10+
and distribution as defined by Sections 1 through 9 of this document.
11+
12+
"Licensor" shall mean the copyright owner or entity authorized by
13+
the copyright owner that is granting the License.
14+
15+
"Legal Entity" shall mean the union of the acting entity and all
16+
other entities that control, are controlled by, or are under common
17+
control with that entity. For the purposes of this definition,
18+
"control" means (i) the power, direct or indirect, to cause the
19+
direction or management of such entity, whether by contract or
20+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
21+
outstanding shares, or (iii) beneficial ownership of such entity.
22+
23+
"You" (or "Your") shall mean an individual or Legal Entity
24+
exercising permissions granted by this License.
25+
26+
"Source" form shall mean the preferred form for making modifications,
27+
including but not limited to software source code, documentation
28+
source, and configuration files.
29+
30+
"Object" form shall mean any form resulting from mechanical
31+
transformation or translation of a Source form, including but
32+
not limited to compiled object code, generated documentation,
33+
and conversions to other media types.
34+
35+
"Work" shall mean the work of authorship, whether in Source or
36+
Object form, made available under the License, as indicated by a
37+
copyright notice that is included in or attached to the work
38+
(an example is provided in the Appendix below).
39+
40+
"Derivative Works" shall mean any work, whether in Source or Object
41+
form, that is based on (or derived from) the Work and for which the
42+
editorial revisions, annotations, elaborations, or other modifications
43+
represent, as a whole, an original work of authorship. For the purposes
44+
of this License, Derivative Works shall not include works that remain
45+
separable from, or merely link (or bind by name) to the interfaces of,
46+
the Work and Derivative Works thereof.
47+
48+
"Contribution" shall mean any work of authorship, including
49+
the original version of the Work and any modifications or additions
50+
to that Work or Derivative Works thereof, that is intentionally
51+
submitted to Licensor for inclusion in the Work by the copyright owner
52+
or by an individual or Legal Entity authorized to submit on behalf of
53+
the copyright owner. For the purposes of this definition, "submitted"
54+
means any form of electronic, verbal, or written communication sent
55+
to the Licensor or its representatives, including but not limited to
56+
communication on electronic mailing lists, source code control systems,
57+
and issue tracking systems that are managed by, or on behalf of, the
58+
Licensor for the purpose of discussing and improving the Work, but
59+
excluding communication that is conspicuously marked or otherwise
60+
designated in writing by the copyright owner as "Not a Contribution."
61+
62+
"Contributor" shall mean Licensor and any individual or Legal Entity
63+
on behalf of whom a Contribution has been received by Licensor and
64+
subsequently incorporated within the Work.
65+
66+
2. Grant of Copyright License. Subject to the terms and conditions of
67+
this License, each Contributor hereby grants to You a perpetual,
68+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
69+
copyright license to reproduce, prepare Derivative Works of,
70+
publicly display, publicly perform, sublicense, and distribute the
71+
Work and such Derivative Works in Source or Object form.
72+
73+
3. Grant of Patent License. Subject to the terms and conditions of
74+
this License, each Contributor hereby grants to You a perpetual,
75+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
76+
(except as stated in this section) patent license to make, have made,
77+
use, offer to sell, sell, import, and otherwise transfer the Work,
78+
where such license applies only to those patent claims licensable
79+
by such Contributor that are necessarily infringed by their
80+
Contribution(s) alone or by combination of their Contribution(s)
81+
with the Work to which such Contribution(s) was submitted. If You
82+
institute patent litigation against any entity (including a
83+
cross-claim or counterclaim in a lawsuit) alleging that the Work
84+
or a Contribution incorporated within the Work constitutes direct
85+
or contributory patent infringement, then any patent licenses
86+
granted to You under this License for that Work shall terminate
87+
as of the date such litigation is filed.
88+
89+
4. Redistribution. You may reproduce and distribute copies of the
90+
Work or Derivative Works thereof in any medium, with or without
91+
modifications, and in Source or Object form, provided that You
92+
meet the following conditions:
93+
94+
(a) You must give any other recipients of the Work or
95+
Derivative Works a copy of this License; and
96+
97+
(b) You must cause any modified files to carry prominent notices
98+
stating that You changed the files; and
99+
100+
(c) You must retain, in the Source form of any Derivative Works
101+
that You distribute, all copyright, patent, trademark, and
102+
attribution notices from the Source form of the Work,
103+
excluding those notices that do not pertain to any part of
104+
the Derivative Works; and
105+
106+
(d) If the Work includes a "NOTICE" text file as part of its
107+
distribution, then any Derivative Works that You distribute
108+
must include a readable copy of the attribution notices
109+
contained within such NOTICE file, excluding those notices
110+
that do not pertain to any part of the Derivative Works,
111+
in at least one of the following places: within a NOTICE
112+
text file distributed as part of the Derivative Works; within
113+
the Source form or documentation, if provided along with
114+
the Derivative Works; or, within a display generated by the
115+
Derivative Works, if and wherever such third-party notices
116+
normally appear. The contents of the NOTICE file are for
117+
informational purposes only and do not modify the License.
118+
You may add Your own attribution notices within Derivative
119+
Works that You distribute, alongside or as an addendum to
120+
the NOTICE text from the Work, provided that such additional
121+
attribution notices cannot be construed as modifying the
122+
License.
123+
124+
You may add Your own copyright statement to Your modifications and
125+
may provide additional or different license terms and conditions
126+
for use, reproduction, or distribution of Your modifications, or
127+
for any such Derivative Works as a whole, provided Your use,
128+
reproduction, and distribution of the Work otherwise complies with
129+
the conditions stated in this License.
130+
131+
5. Submission of Contributions. Unless You explicitly state otherwise,
132+
any Contribution intentionally submitted for inclusion in the Work
133+
by You to the Licensor shall be under the terms and conditions of
134+
this License, without any additional terms or conditions.
135+
Notwithstanding the above, nothing herein shall supersede or modify
136+
the terms of any separate license agreement you may have executed
137+
with Licensor regarding such Contributions.
138+
139+
6. Trademarks. This License does not grant permission to use the trade
140+
names, trademarks, service marks, or product names of the Licensor,
141+
except as required for reasonable and customary use in describing the
142+
origin of the Work and reproducing the content of the NOTICE file.
143+
144+
7. Disclaimer of Warranty. Unless required by applicable law or
145+
agreed to in writing, Licensor provides the Work (and each
146+
Contributor provides its Contributions) on an "AS IS" BASIS,
147+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
148+
implied, including, without limitation, any warranties or conditions
149+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
150+
PARTICULAR PURPOSE. You are solely responsible for determining the
151+
appropriateness of using or redistributing the Work and assume any
152+
risks associated with Your exercise of permissions under this License.
153+
154+
8. Limitation of Liability. In no event and under no legal theory,
155+
whether in tort (including negligence), contract, or otherwise,
156+
unless required by applicable law (such as deliberate and grossly
157+
negligent acts) or agreed to in writing, shall any Contributor be
158+
liable to You for damages, including any direct, indirect, special,
159+
incidental, or consequential damages of any character arising as a
160+
result of this License or out of the use or inability to use the
161+
Work (including but not limited to damages for loss of goodwill,
162+
work stoppage, computer failure or malfunction, or any and all
163+
other commercial damages or losses), even if such Contributor
164+
has been advised of the possibility of such damages.
165+
166+
9. Accepting Warranty or Additional Liability. While redistributing
167+
the Work or Derivative Works thereof, You may choose to offer,
168+
and charge a fee for, acceptance of support, warranty, indemnity,
169+
or other liability obligations and/or rights consistent with this
170+
License. However, in accepting such obligations, You may act only
171+
on Your own behalf and on Your sole responsibility, not on behalf
172+
of any other Contributor, and only if You agree to indemnify,
173+
defend, and hold each Contributor harmless for any liability
174+
incurred by, or claims asserted against, such Contributor by reason
175+
of your accepting any such warranty or additional liability.
176+
177+
END OF TERMS AND CONDITIONS
178+
179+
APPENDIX: How to apply the Apache License to your work.
180+
181+
To apply the Apache License to your work, attach the following
182+
boilerplate notice, with the fields enclosed by brackets "[]"
183+
replaced with your own identifying information. (Don't include
184+
the brackets!) The text should be enclosed in the appropriate
185+
comment syntax for the file format. We also recommend that a
186+
file or class name and description of purpose be included on the
187+
same "printed page" as the copyright notice for easier
188+
identification within third-party archives.
189+
190+
Copyright 2026 ObjectStack
191+
192+
Licensed under the Apache License, Version 2.0 (the "License");
193+
you may not use this file except in compliance with the License.
194+
You may obtain a copy of the License at
195+
196+
http://www.apache.org/licenses/LICENSE-2.0
197+
198+
Unless required by applicable law or agreed to in writing, software
199+
distributed under the License is distributed on an "AS IS" BASIS,
200+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
201+
See the License for the specific language governing permissions and
202+
limitations under the License.

0 commit comments

Comments
 (0)