@objectstack/types 17.0.0-rc.5 → 17.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +2293 -0
- package/dist/index.d.mts +429 -6
- package/dist/index.d.ts +429 -6
- package/dist/index.js +187 -3
- package/dist/index.js.map +1 -1
- package/dist/index.mjs +176 -2
- package/dist/index.mjs.map +1 -1
- package/package.json +2 -2
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,2298 @@
|
|
|
1
1
|
# @objectstack/types
|
|
2
2
|
|
|
3
|
+
## 17.0.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- 879ea13: ADR-0105 Phase 0 + Phase 1: group tenancy posture; organization scope as a
|
|
8
|
+
first-class authorization dimension.
|
|
9
|
+
|
|
10
|
+
> This release carries BREAKING spec removals (see "Enforce-or-remove" below)
|
|
11
|
+
> but is recorded as `minor`: every publishable package is in the Changesets
|
|
12
|
+
> lockstep group, so one `major` would promote the whole monorepo. Breaking
|
|
13
|
+
> changes ship as `minor` during the launch window — the migration notes below
|
|
14
|
+
> are what reach consumers in `CHANGELOG.md`.
|
|
15
|
+
|
|
16
|
+
## Tenancy is now a spectrum (D1)
|
|
17
|
+
|
|
18
|
+
`single | group | isolated`, resolved by the `tenancy` service and selected with
|
|
19
|
+
the new `OS_TENANCY_POSTURE` env var. Existing deployments are unchanged:
|
|
20
|
+
`OS_TENANCY_POSTURE` unset derives the posture from `OS_MULTI_ORG_ENABLED`
|
|
21
|
+
(`true` ⇒ `isolated`, else `single`). An unrecognized value throws at boot
|
|
22
|
+
rather than silently landing in a posture with no organization wall.
|
|
23
|
+
|
|
24
|
+
- `single` — no wall (unchanged).
|
|
25
|
+
- `group` — **new.** Organizations are membership boundaries over one shared
|
|
26
|
+
dataset; Layer 0 becomes `organization_id IN accessible_org_ids` (union / MOAC
|
|
27
|
+
semantics). Enforced by the OPEN engine.
|
|
28
|
+
- `isolated` — today's `multi`, renamed. Behavior, enterprise `org-scoping`
|
|
29
|
+
probe and degraded-boot handling all unchanged.
|
|
30
|
+
|
|
31
|
+
## Organization scope is a first-class context field (D2)
|
|
32
|
+
|
|
33
|
+
`ExecutionContext.accessible_org_ids` — every organization the caller holds a
|
|
34
|
+
currently-valid membership in (ADR-0091 validity windows) — is resolved once by
|
|
35
|
+
`resolveAuthzContext` and carried by every transport. The `group` wall reads it
|
|
36
|
+
directly; RLS policies may reference it as
|
|
37
|
+
`organization_id IN (current_user.accessible_org_ids)`. An empty or absent set
|
|
38
|
+
fails the wall closed.
|
|
39
|
+
|
|
40
|
+
Only the Layer 0 PREDICATE widens. Composition is untouched: the wall is still
|
|
41
|
+
computed independently of the RLS compiler, AND-composed outermost, and
|
|
42
|
+
crossable only by a true `PLATFORM_ADMIN` on a posture-permitting object — so
|
|
43
|
+
ADR-0095's W1/W2 invariants hold in every posture.
|
|
44
|
+
|
|
45
|
+
## Two P0 correctness fixes (D3, D4) — behavior changes
|
|
46
|
+
|
|
47
|
+
**D3 — app-authored org-scoped RLS policies are no longer silently dropped**
|
|
48
|
+
(finding F1, framework#3539). `collectRLSPolicies` used to strip any policy whose
|
|
49
|
+
`using` contained the substring `current_user.organization_id` when isolation was
|
|
50
|
+
inactive, which swallowed app-authored policies as well as the platform's own.
|
|
51
|
+
Stripping is now decided by PROVENANCE (identity against the shipped
|
|
52
|
+
declaration). **Upgrade impact:** in a deployment with no organization wall, an
|
|
53
|
+
app-authored policy referencing the active organization is now RETAINED and
|
|
54
|
+
fails closed (zero rows) with a one-time warning, where it previously vanished
|
|
55
|
+
and the object read unscoped. `getReadFilter` shared the defect, so analytics and
|
|
56
|
+
raw-SQL consumers were affected too. If a policy was only ever meant for
|
|
57
|
+
multi-org, delete it or install `@objectstack/organizations`.
|
|
58
|
+
|
|
59
|
+
**D4 — `viewAllRecords`/`modifyAllRecords` never cross an organization
|
|
60
|
+
boundary** (finding F2, framework#3540). Under a wall-less posture nothing
|
|
61
|
+
bounded the wildcard superuser bits `organization_admin` carries, so a
|
|
62
|
+
deployment that accumulated organizations (personal orgs on signup) made every
|
|
63
|
+
owner/admin an environment-wide superuser. `auto-org-admin-grant` now grants a
|
|
64
|
+
de-VAMA'd `organization_admin_no_bypass` variant when no wall is enforced, and
|
|
65
|
+
revokes the superseded variant whenever the posture changes. **Upgrade impact:**
|
|
66
|
+
in `single` posture an org owner/admin keeps full CRUD but loses the blanket
|
|
67
|
+
ownership/sharing/RLS bypass. Deliberate deployment-wide visibility remains
|
|
68
|
+
available through `admin_full_access` or an explicitly authored permission set —
|
|
69
|
+
it just stops being a side effect of a better-auth membership role.
|
|
70
|
+
|
|
71
|
+
## Engine-owned organization stamping (D5)
|
|
72
|
+
|
|
73
|
+
Under any wall-enforcing posture the engine stamps `organization_id` from the
|
|
74
|
+
caller's active organization on an insert that omits it, and validates every
|
|
75
|
+
supplied value against the wall. Idempotent with the enterprise auto-stamp
|
|
76
|
+
(neither overwrites a supplied value). This also closes a real hole: the
|
|
77
|
+
pre-existing post-image check required a non-array payload, so a BULK insert
|
|
78
|
+
could carry a forged `organization_id` per row. One forged row now denies the
|
|
79
|
+
whole write.
|
|
80
|
+
|
|
81
|
+
## Group structure, extension fields and red-line lints (D6, D7)
|
|
82
|
+
|
|
83
|
+
- `sys_organization` gains `parent_organization_id` and `sort_order` — a
|
|
84
|
+
**reporting dimension only**.
|
|
85
|
+
- New lint `validateOrgAxisRedLines` (`org-axis-permission-inheritance`,
|
|
86
|
+
`org-axis-cross-org-bu-grant`), wired into `os lint` / `os compile` /
|
|
87
|
+
`os validate`: an RLS policy or sharing rule that walks the org tree is an
|
|
88
|
+
error, as is a business-unit grant on a platform-global object.
|
|
89
|
+
- Extension fields on better-auth-managed objects ride the existing ADR-0092
|
|
90
|
+
whitelist. A new guard derives better-auth's real field surface from
|
|
91
|
+
`getAuthTables()` at the pinned version and fails the build on any name
|
|
92
|
+
collision, so a library upgrade cannot silently take ownership of a column.
|
|
93
|
+
|
|
94
|
+
## Enforce-or-remove (D11) — BREAKING
|
|
95
|
+
|
|
96
|
+
Both removals are of surface that had **zero runtime consumers**, so no
|
|
97
|
+
behavior changes; authoring them is now a no-op instead of a lint warning.
|
|
98
|
+
|
|
99
|
+
- **`PermissionSet.contextVariables` — REMOVED.** The RLS compiler never read
|
|
100
|
+
it. FROM → TO: a set a policy needs as `field IN (current_user.<key>)` is now
|
|
101
|
+
supplied by a registered membership resolver (below); a constant belongs in
|
|
102
|
+
the policy itself as a literal (`status = 'published'`).
|
|
103
|
+
- **`Territory` / `TerritoryModel` / `TerritoryType` (`security/territory.zod.ts`)
|
|
104
|
+
— REMOVED.** No runtime object, stack field or resolver existed. FROM → TO:
|
|
105
|
+
matrix requirements are served by multi-position × business-unit anchoring; a
|
|
106
|
+
generalized dimension-security module will arrive with its own ADR.
|
|
107
|
+
- **`ExecutionContext.rlsMembership` — PRODUCTIZED.** The bag the compiler has
|
|
108
|
+
merged since ADR-0056 finally has a producer: register an
|
|
109
|
+
`IRlsMembershipResolver` (`@objectstack/spec/contracts`) under the
|
|
110
|
+
`rls-membership-resolver` service, declaring the keys it owns. Fail-closed by
|
|
111
|
+
construction — an unresolved key makes its policies drop out. Kernel-owned
|
|
112
|
+
keys (`accessible_org_ids`, `org_user_ids`, …) are reserved and cannot be
|
|
113
|
+
overwritten from this seam.
|
|
114
|
+
|
|
115
|
+
## Edition boundary (D12)
|
|
116
|
+
|
|
117
|
+
The `group` posture's enforcement primitives ship OPEN — the union wall,
|
|
118
|
+
`accessible_org_ids` resolution, D5 stamping/validation, the D3/D4 correctness
|
|
119
|
+
fixes and the D6 lints — because the correctness of a wall is never a paid
|
|
120
|
+
feature (cloud ADR-0016 铁律「强制免费、治理收费」). `isolated` keeps its existing
|
|
121
|
+
enterprise `org-scoping` probe, so the current commercial boundary for
|
|
122
|
+
legal-entity isolation is unchanged by this release.
|
|
123
|
+
|
|
124
|
+
- 28ad90e: feat(types,cloud-connection,lint,cli): ADR-0120 17.x 收尾 —— `isolated` 安装期姿态硬门(D5e)、D5c 重拼写 advisory、成文契约扫荡与三姿态 conformance (#5081)
|
|
125
|
+
|
|
126
|
+
ADR-0120 17.x 波的第三块,也是最后一块。前两块已在 main 上:#5212(driver 侧
|
|
127
|
+
D3+D4 —— `COALESCE(organization_id, '__global__')` 物化、drift 两侧同步、重复预检)
|
|
128
|
+
与 #5208(spec 词汇 `'organization'` + D5a/D5b lint)。本次补齐三件事:安装期的
|
|
129
|
+
姿态决策点、剩余的成文契约、以及把「一个 app 包跑遍三种姿态」从假设变成测试。
|
|
130
|
+
|
|
131
|
+
**D5e —— 装进 `isolated` 环境时的硬门。** 词汇本身是姿态无关的:作者说的是业务
|
|
132
|
+
边界(`'organization'` 一个组织一份 / `'global'` 整个安装一份),没有任何索引形状
|
|
133
|
+
读姿态。唯一的残留在一个方向上:`isolated` 下组织就是**不同客户**,此时 app 业务
|
|
134
|
+
对象上的 `'global'` 唯一既跨客户过度约束,又变成跨客户的存在性预言机(S10/S14)。
|
|
135
|
+
维护者裁定这是**硬门而非 advisory**:把带 `'global'` 唯一(非 `sys` 对象)的 app
|
|
136
|
+
装进 `isolated` 环境会**停下来并逐索引列出**,安装者(通常是 AI agent)要么确认它
|
|
137
|
+
确实是平台级的,要么改写为 `'organization'`;确认按 ADR-0104 attestation 风格
|
|
138
|
+
留痕在安装清单里(`InstalledManifestEntry.globalUniqueAttestation` —— 确认了什么、
|
|
139
|
+
谁确认的、何时、在哪个姿态下问的),**之后不复问**。
|
|
140
|
+
|
|
141
|
+
- 停下的安装**什么都不留**:先于 hot-register 和任何 ledger 写入,所以作者改完
|
|
142
|
+
元数据可以直接重试,不需要先卸载。
|
|
143
|
+
- 逐索引确认是有牙齿的:`confirmGlobalUniques` 收 `true` 或明确的 id 数组,只确认
|
|
144
|
+
其中一条仍会在剩下的那条上停住。
|
|
145
|
+
- 升级引入的**新**约束会被问,老的答案继续算数。
|
|
146
|
+
- 另一个姿态下给出的确认**不算同意** —— `isolated` 那个问题在 `single` 下从未被
|
|
147
|
+
问过,所以按「未确认」处理(唯一不会静默放行跨客户约束的方向)。
|
|
148
|
+
- ⛔ **永不做成启动期告警**(#4884 纪律)。boot 时的 rehydrate 不评估此门;门够不到
|
|
149
|
+
的两类存量 —— 门禁上线前的安装、装后姿态变更的环境 —— 由 `os doctor` 与
|
|
150
|
+
`os migrate plan` 的 advisory 形态覆盖。
|
|
151
|
+
|
|
152
|
+
判定里有三条是承重的,别「简化」掉:声明索引上的裸 `unique: true` **算**(D1 说它
|
|
153
|
+
就是 `'global'` 的位置式拼写,排除它等于让整个 17.x 可以靠拼写绕过);字段级
|
|
154
|
+
`true` **不算**(它是 `'organization'`,永久合法);`sys_`/`base_` 对象**不算**
|
|
155
|
+
(S5 那批引擎幂等键天然就是平台级的,每次安装都问一遍就是 #4884 的误报类)。
|
|
156
|
+
|
|
157
|
+
CLI: `os package install` 新增 `--confirm-global-uniques`,并把 409 渲染成可读的
|
|
158
|
+
逐条清单而不是一句 "Install failed (409)"。
|
|
159
|
+
|
|
160
|
+
**D5c —— 遗留手写组织复合索引的 advisory。** 新规则
|
|
161
|
+
`unique/legacy-organization-composite`:声明的唯一索引自己列出了组织列
|
|
162
|
+
(`{ fields: ['name','organization_id'], unique: true }`)—— 这是词汇出现之前手写
|
|
163
|
+
per-organization 的写法。它读起来像「每组织唯一」,物化出来却是普通复合索引,而
|
|
164
|
+
SQL UNIQUE 是 NULL-distinct 的:组织列为 NULL 的行上它**什么都不约束**(#5030),
|
|
165
|
+
在单组织部署上那就是每一行。改写成 `unique: 'organization'`(`fields` 原样保留,
|
|
166
|
+
driver 会把已列出的组织列**就地**变成 NULL-safe 形式)正是补上这个洞的动作。
|
|
167
|
+
**永远只是 advisory,永远不自动修**:老拼写永久合法、零强制 drift,而 opt-in 是
|
|
168
|
+
真实的物理收紧,要走 D4 的 `recreate_index` + 重复预检。
|
|
169
|
+
|
|
170
|
+
**D6 —— 成文契约扫荡。** `content/docs/data-modeling/indexing.mdx` 的
|
|
171
|
+
§Two ways to say "unique" 全节按新词汇重写(含 `os:check` 代码块);
|
|
172
|
+
`content/docs/protocol/objectql/schema.mdx` 的 §Uniqueness and tenancy 重写为
|
|
173
|
+
§Uniqueness and scope —— 其中那句「单租户部署不受影响,租户列是常量,复合索引
|
|
174
|
+
退化为单列索引」是 #5030 **证伪过的原话**,现已替换为 D3 的 NULL-safe 事实;
|
|
175
|
+
`content/docs/deployment/cli.mdx` 的 `replace_unique_index` / `recreate_index`
|
|
176
|
+
条目补上 NULL-safe 形状与重复预检;`content/docs/references/**` 经
|
|
177
|
+
`gen:schema && gen:docs` 再生成,未手改。
|
|
178
|
+
|
|
179
|
+
按 ADR-0120 Resolved #2 的非规范性引导(官方示例/脚手架/生成器在新代码中输出
|
|
180
|
+
显式拼写),`skills/objectstack-data/**` 的索引与校验规则整体扫过:声明索引一律
|
|
181
|
+
说清 scope,并新增一节完整讲 `'organization'` 的 NULL-safe 语义与「永远不写姿态」。
|
|
182
|
+
顺带修掉那里长期使用的 `tenant_id` —— 平台的列叫 `organization_id`。
|
|
183
|
+
`examples/**`、`create-objectstack` 模板与 `os generate` 经核查**根本没有声明任何
|
|
184
|
+
唯一约束**,故无可扫;这是核查结论,不是遗漏。
|
|
185
|
+
|
|
186
|
+
**三姿态 conformance(ADR §Acceptance tests)。** 同一个 fixture app 在
|
|
187
|
+
`single | group | isolated` 三姿态下启动,逐 S 行用**真实的违规插入**断言 enforcement
|
|
188
|
+
(S1/S2/S3/S4/S5/S6/S7/S8/S9/S11/S12),并逐姿态捕获物化出的索引键,断言三者
|
|
189
|
+
**逐字节相同** —— 「没有任何索引形状读姿态」这句话一旦有两者不同就是假的。相同性
|
|
190
|
+
断言配了一条正向断言(对着期望的键形状),这样「三次都什么都没建」不会读成「一致」。
|
|
191
|
+
外加 ADR 只要的那一条 transition smoke:在 `single` 下建库、`isolated` 下重新打开,
|
|
192
|
+
drift op 为零。
|
|
193
|
+
|
|
194
|
+
对既有部署的影响:除新增的安装期确认外,本次不改变任何已有物化行为。字段级
|
|
195
|
+
`unique: true` 一如既往合法。
|
|
196
|
+
|
|
197
|
+
- 840ee4b: fix(analytics,runtime,types): gate cube auto-inference on object existence; stop the dispatcher boundary returning raw SQL (#3867)
|
|
198
|
+
|
|
199
|
+
Two independent defects on the `/analytics` surface, found while verifying #3770
|
|
200
|
+
against a real server. On an authenticated CRM dev server, before this change:
|
|
201
|
+
|
|
202
|
+
```
|
|
203
|
+
POST /api/v1/analytics/query {"cube":"sqlite_master","measures":["count"],"dimensions":["type"]}
|
|
204
|
+
→ 200 {"rows":[{"type":"index","count":262},{"type":"table","count":71},{"type":"view","count":1}],
|
|
205
|
+
"sql":"SELECT type AS \"type\", COUNT(*) AS \"count\" FROM \"sqlite_master\" GROUP BY type"}
|
|
206
|
+
```
|
|
207
|
+
|
|
208
|
+
That is SQLite's internal schema table — never a registered object — read
|
|
209
|
+
successfully through the analytics endpoint. Not merely "the name reaches the
|
|
210
|
+
driver and errors": **any table the connection can see was readable.**
|
|
211
|
+
|
|
212
|
+
**① The cube name reached the driver as a table name.** `AnalyticsService.ensureCube`
|
|
213
|
+
auto-infers a minimal Cube when none is registered, with `cube.sql = <the queried
|
|
214
|
+
name>`. That is the intended "metric over an object" path — an `object-metric` KPI
|
|
215
|
+
widget queries `crm_account` with no authored Cube — but it accepted _any_ string,
|
|
216
|
+
so the endpoint could aggregate over an arbitrary physical table. The
|
|
217
|
+
analytics-side twin of the data-path gap #3770 closed, and it was not covered by
|
|
218
|
+
that fix: #3770 gated the protocol's `analyticsQuery`, which is the _degraded
|
|
219
|
+
fallback_; a deployment with `@objectstack/service-analytics` installed runs the
|
|
220
|
+
real engine instead (`ctx.replaceService`).
|
|
221
|
+
|
|
222
|
+
Inference is now gated on the same schema registry the data path consults, via a
|
|
223
|
+
new optional `AnalyticsServiceConfig.isRegisteredObject` that `plugin.ts` wires
|
|
224
|
+
from the `data` engine's `getObject`. Three-way rule: a registered Cube runs
|
|
225
|
+
untouched (its `sql` is whatever it declares); an unregistered name that IS an
|
|
226
|
+
object still auto-infers exactly as before; neither → `CUBE_NOT_FOUND` / 404
|
|
227
|
+
raised before any SQL exists, naming both ways to make the request valid. With no
|
|
228
|
+
probe configured the gate stands down and warns once — the same tiering #3770
|
|
229
|
+
took for a missing registry. `generateSql` (`/analytics/sql`) is gated too.
|
|
230
|
+
|
|
231
|
+
**② The dispatcher boundary returned `err.message` verbatim.** `errorResponseBase`
|
|
232
|
+
is the single error exit for _every_ route the dispatcher plugin mounts —
|
|
233
|
+
`/analytics`, `/packages`, `/i18n`, `/storage`, `/automation`, `/auth`,
|
|
234
|
+
`/notifications`, `/mcp`. `@objectstack/rest` has guarded its data routes against
|
|
235
|
+
driver dumps forever (`mapDataError`); this boundary guarded nothing, so any
|
|
236
|
+
driver error on any of those routes shipped its SQL to the client. Unlike ①, this
|
|
237
|
+
half is unconditional — it does not depend on the cube being invalid.
|
|
238
|
+
|
|
239
|
+
The leak heuristic moved out of `rest-server.ts` into `@objectstack/types` as
|
|
240
|
+
`looksLikeInternalErrorLeak` (both packages already depend on it) and is now
|
|
241
|
+
applied at both boundaries — one predicate, one place to widen when a new
|
|
242
|
+
dialect's phrasing shows up. `mapDataError`'s behaviour is unchanged. At the
|
|
243
|
+
dispatcher it applies **only to 5xx**: a 4xx message is a deliberate
|
|
244
|
+
business/validation answer and must reach the caller intact. Sanitising costs no
|
|
245
|
+
diagnostics — the untouched error still reaches `errorReporter` through the
|
|
246
|
+
existing `__obsRecordedError` side-channel.
|
|
247
|
+
|
|
248
|
+
**Also fixed in the same function:** `errorResponseBase` read only
|
|
249
|
+
`err.statusCode`, while domain errors across this codebase carry `status` (and
|
|
250
|
+
`HttpDispatcher.errorFromThrown` already reads `status` first). Every deliberate
|
|
251
|
+
4xx thrown through a dispatcher route — including #3770's `OBJECT_NOT_FOUND` on
|
|
252
|
+
the analytics fallback path — was rendered as a **500**. It now reads `status`
|
|
253
|
+
then `statusCode`.
|
|
254
|
+
|
|
255
|
+
**Behaviour change.** `/analytics/query` and `/analytics/sql` return 404
|
|
256
|
+
`CUBE_NOT_FOUND` for a cube that is neither registered nor a registered object;
|
|
257
|
+
previously the name was passed to the driver. Dashboards and KPI widgets pointed
|
|
258
|
+
at real objects or authored cubes are unaffected. A 5xx on a dispatcher route
|
|
259
|
+
whose message looks like a driver dump now reads `Internal server error` — check
|
|
260
|
+
server logs or your error reporter for the original.
|
|
261
|
+
|
|
262
|
+
- 64cd010: fix(runtime,types)!: `/analytics/query` no longer echoes RLS policy field names — the declared-server-fault withhold is shared by both HTTP boundaries (#5811)
|
|
263
|
+
|
|
264
|
+
**Observable behaviour change — read this if you read, log, or assert on
|
|
265
|
+
`error.message` from a dispatcher-plugin route.** An error that **declares a
|
|
266
|
+
server fault** in the ADR-0112 envelope (`status >= 500` _and_ a non-empty
|
|
267
|
+
`code`) now leaves `dispatcher-plugin.errorResponseBase` with its message
|
|
268
|
+
replaced by `"Internal server error"`. It previously reached the caller verbatim
|
|
269
|
+
unless it happened to _sound_ like a SQL/driver dump. This applies to every route
|
|
270
|
+
that plugin mounts — `/analytics`, `/packages`, `/i18n`, `/automation`, `/auth`,
|
|
271
|
+
`/notifications`, `/mcp`, … — not only the one that motivated it. Nothing a
|
|
272
|
+
machine reads changed: the producer's `code` still arrives in the response
|
|
273
|
+
(`error.code`, promoted there from `details` by the shared envelope builder,
|
|
274
|
+
#3842), the status is untouched, and the full original text still goes to the
|
|
275
|
+
server log and `errorReporter` via `__obsRecordedError`.
|
|
276
|
+
|
|
277
|
+
## What was wrong
|
|
278
|
+
|
|
279
|
+
#5367 (maintainer ruling 2026-08-06) made `read-scope-sql.ts`'s ten fail-closed
|
|
280
|
+
RLS lowering refusals `READ_SCOPE_COMPILE_FAILED` / 500 and taught
|
|
281
|
+
`POST /analytics/dataset/query` to withhold their message, because those messages
|
|
282
|
+
name the field names and comparands of an **administrator's** sharing rule:
|
|
283
|
+
|
|
284
|
+
```
|
|
285
|
+
[read-scope-sql] unsafe field identifier "secret_policy_field" — refusing to
|
|
286
|
+
build read scope (fail-closed).
|
|
287
|
+
```
|
|
288
|
+
|
|
289
|
+
The caller never wrote that field name and must not be able to read it out of an
|
|
290
|
+
error body. But the **sibling** analytics face was never closed.
|
|
291
|
+
`compileScopedFilterToSql` runs on both `NativeSQLStrategy.applyReadScope` and
|
|
292
|
+
`ObjectQLStrategy`'s echoed SQL, both of which serve `POST /analytics/query`,
|
|
293
|
+
which exits through `dispatcher-plugin.errorResponseBase`. That exit's only
|
|
294
|
+
message guard was `looksLikeInternalErrorLeak` — a heuristic over SQL/driver
|
|
295
|
+
_phrasing_ — and all eleven read-scope message shapes return `false` from it.
|
|
296
|
+
Measured at that boundary: **11 of 11 echoed verbatim**, at 500, with the policy
|
|
297
|
+
content in `error.message`. A real reachable disclosure, not a theoretical one.
|
|
298
|
+
|
|
299
|
+
## What changed
|
|
300
|
+
|
|
301
|
+
- **`@objectstack/types` gains `declaresServerFault(err)`**, exported from
|
|
302
|
+
`error-leak.ts` beside `looksLikeInternalErrorLeak`. The heuristic asks whether
|
|
303
|
+
a message _sounds_ internal; the declaration asks whether the producer _said
|
|
304
|
+
so_. `error-leak.ts`'s own file header already states the principle — "do not
|
|
305
|
+
ship driver internals to clients" is a property of the HTTP boundary, not of
|
|
306
|
+
one router — and this is the second predicate that principle asks for.
|
|
307
|
+
- **Both boundaries read it.** `dispatcher-plugin.errorResponseBase` gains the
|
|
308
|
+
withhold (the fix); `rest-server.ts`'s `/analytics/dataset/query` catch drops
|
|
309
|
+
its in-line copy of the same test in favour of the shared one. #5808 wrote that
|
|
310
|
+
rule in-line on purpose — promoting a rule with one consumer is a speculative
|
|
311
|
+
surface — and this is the second consumer, so it was promoted rather than
|
|
312
|
+
duplicated (`#3843`/`#3867` paid for the two-implementations shape twice).
|
|
313
|
+
The REST face's verdict is unchanged in every case: same `status >= 500` plus
|
|
314
|
+
non-empty `code` test, over the same two fields.
|
|
315
|
+
|
|
316
|
+
## What deliberately did NOT change
|
|
317
|
+
|
|
318
|
+
- ⛔ **This is not "withhold every 5xx".** #5667 kept **undeclared** 5xx errors
|
|
319
|
+
legible on purpose: a bare `Error` from our own code ("no strategy can handle
|
|
320
|
+
query …") is the operator's own bug report, names nothing tenant-sensitive, and
|
|
321
|
+
still falls to `looksLikeInternalErrorLeak` alone. A 5xx carrying only half an
|
|
322
|
+
envelope (a status with no code) is likewise still readable — inventing the
|
|
323
|
+
withhold for it would be the consumer-side leniency Prime Directive #12 removes.
|
|
324
|
+
- **4xx is untouched.** `declaresServerFault` requires `status >= 500`, so a
|
|
325
|
+
deliberate business/validation answer can never be swallowed by it.
|
|
326
|
+
- **`statusCode` is not accepted as a substitute for `status`.** `status` is the
|
|
327
|
+
channel ADR-0112 declares; making a disclosure rule depend on which spelling a
|
|
328
|
+
producer reached for would be the same leniency in a different place.
|
|
329
|
+
- **The heuristic was not taught to recognise `[read-scope-sql]`.** That would be
|
|
330
|
+
more prose sniffing — the mechanism #5352/#5367 exist to remove — and would only
|
|
331
|
+
ever cover the family someone remembered to add.
|
|
332
|
+
|
|
333
|
+
Coverage: `analytics-query-read-scope-withhold.test.ts` (runtime) drives six RLS
|
|
334
|
+
policy shapes end-to-end through a **real** `AnalyticsService` on the real
|
|
335
|
+
native-SQL path and the real mounted route, asserting the 500, that the whole
|
|
336
|
+
serialized body contains no policy detail, that `error.code` still carries
|
|
337
|
+
`READ_SCOPE_COMPILE_FAILED`, and that the full text is still on the
|
|
338
|
+
`__obsRecordedError` side-channel — plus a positive control and both sides of the
|
|
339
|
+
declared-vs-undeclared tiering. `error-leak.test.ts` (types) pins the predicate
|
|
340
|
+
directly, including that all eleven read-scope shapes stay invisible to the
|
|
341
|
+
heuristic. The REST face's existing `analytics-read-scope-refusal-envelope.test.ts`
|
|
342
|
+
is green before and after, unchanged, which is the pin on the refactor.
|
|
343
|
+
|
|
344
|
+
- 9f5cc79: A bulk write's per-row `errors[].httpStatus` carries the status its producer declared, in any spelling (#8570)
|
|
345
|
+
|
|
346
|
+
`toRowApiError` set the limb from `err.status` alone, so two well-defined client
|
|
347
|
+
refusals shipped a batch row with no status at all: objectql's `ValidationError`
|
|
348
|
+
(a 400 recognisable by shape, which deliberately declares no `status`) and
|
|
349
|
+
`plugin-approvals`' record lock (a 409 spelled `statusCode`). Sibling rows in the
|
|
350
|
+
same response did carry one — `rowRequiredIdError` → 400,
|
|
351
|
+
`recordNotFoundError` → 404 — so a caller branching on `httpStatus` to tell "fix
|
|
352
|
+
your input" from "the server broke" got an answer for some failure rows and
|
|
353
|
+
silence for others, with nothing saying which. Same single-spelling defect #7525
|
|
354
|
+
fixed at the HTTP door, one layer down.
|
|
355
|
+
|
|
356
|
+
The limb now asks `resolveThrownHttpError` — the resolver the HTTP doors and the
|
|
357
|
+
row's `message` limb already answer with — so a refusal declaring `.status`,
|
|
358
|
+
`.statusCode` or the `VALIDATION_FAILED` shape reaches the row as the status it
|
|
359
|
+
always meant. Rows whose throw declared nothing (a driver fault, a hook throwing
|
|
360
|
+
a bare `Error`) still carry no `httpStatus`: the resolver's 500 there is the
|
|
361
|
+
caller's fallback, not a producer's claim, and stamping it would add a field to
|
|
362
|
+
the wire for those populations rather than restore a declared one. `code` reads
|
|
363
|
+
the same resolution, so a row can no longer contradict itself.
|
|
364
|
+
|
|
365
|
+
`ThrownHttpError` gains `declaredStatus` — the resolved status minus the
|
|
366
|
+
fallback, absent when the throw declared none. `status` is unchanged, and every
|
|
367
|
+
boundary that answers with the status itself keeps reading it; the new field is
|
|
368
|
+
for sinks that mirror a status onto response DATA, where a fallback would be an
|
|
369
|
+
invention.
|
|
370
|
+
|
|
371
|
+
- 2a37694: fix(plugin-dev,types): the production escape hatch stops being silent (#3900)
|
|
372
|
+
|
|
373
|
+
`DevPlugin.init()` refuses to run under `NODE_ENV=production` (ADR-0115 D6), and
|
|
374
|
+
`OS_ALLOW_DEV_PLUGIN` overrides that refusal. As shipped, the override returned
|
|
375
|
+
early with **no output at all**: the process ran the development assembly while
|
|
376
|
+
every log line and the ready banner read like an ordinary production start.
|
|
377
|
+
|
|
378
|
+
That reproduces, one level up, the defect the guard exists to close. The guard's
|
|
379
|
+
own precedent says so — `OS_ALLOW_DEGRADED_TENANCY` boots degraded _and brands
|
|
380
|
+
it everywhere an operator looks_, and `OS_ALLOW_DRIVER_CONNECT_FAILURE`'s
|
|
381
|
+
contract is "logged loudly at startup". An escape hatch that says nothing leaves
|
|
382
|
+
the operator's only evidence of a degraded state in an env var they may not have
|
|
383
|
+
set themselves.
|
|
384
|
+
|
|
385
|
+
**The override now brands itself, twice.** A warning at `init()` — emitted
|
|
386
|
+
before any assembly work, so it survives an assembly step that later throws —
|
|
387
|
+
and a repeat on the ready banner, which is the surface an operator actually
|
|
388
|
+
reads:
|
|
389
|
+
|
|
390
|
+
```
|
|
391
|
+
⚠ DEV ASSEMBLY UNDER NODE_ENV=production (OS_ALLOW_DEV_PLUGIN is set) — the boot
|
|
392
|
+
guard was explicitly overridden. This process is running the DEVELOPMENT
|
|
393
|
+
assembly, which is not hardened for production traffic (ADR-0115 D6).
|
|
394
|
+
• Auth secret is the default published inside @objectstack/plugin-dev. It is
|
|
395
|
+
public, so anyone can mint a session this stack accepts. Pass `authSecret`
|
|
396
|
+
explicitly.
|
|
397
|
+
• Data goes to the in-memory driver with persistence disabled — every record
|
|
398
|
+
is lost when this process exits.
|
|
399
|
+
```
|
|
400
|
+
|
|
401
|
+
Only hazards that are live for _that_ configuration are named: the secret line
|
|
402
|
+
is suppressed when the operator passed their own `authSecret`, and the driver
|
|
403
|
+
line when the `driver` toggle is off. The dev-admin seed is deliberately absent
|
|
404
|
+
— `plugin-auth`'s `maybeSeedDevAdmin` is hard-gated to
|
|
405
|
+
`NODE_ENV === 'development'` and cannot fire on this path, so warning about it
|
|
406
|
+
would spend the attention the real hazards need.
|
|
407
|
+
|
|
408
|
+
**New export — `resolveAllowDevPlugin()` (`@objectstack/types`).** The flag moves
|
|
409
|
+
off a bare `process.env['OS_ALLOW_DEV_PLUGIN'] === '1'` and joins the
|
|
410
|
+
`OS_ALLOW_*` family's shared truthy vocabulary, next to
|
|
411
|
+
`resolveAllowDegradedTenancy` / `resolveAllowDriverConnectFailure`.
|
|
412
|
+
|
|
413
|
+
FROM → TO for operators: `OS_ALLOW_DEV_PLUGIN=1` keeps working unchanged.
|
|
414
|
+
`OS_ALLOW_DEV_PLUGIN=true` (and `on` / `yes`, case-insensitive, surrounding
|
|
415
|
+
whitespace ignored) **now takes effect** where the strict comparison previously
|
|
416
|
+
ignored it and failed the boot. That is a widening, in the direction an operator
|
|
417
|
+
setting the flag already intended; falsy and unrecognised values still refuse to
|
|
418
|
+
boot, and unset still means "fail fast". If you were relying on
|
|
419
|
+
`OS_ALLOW_DEV_PLUGIN=true` being inert as a way to keep the guard armed, unset
|
|
420
|
+
the variable instead.
|
|
421
|
+
|
|
422
|
+
No change to the refusal path, which this issue re-verified end to end:
|
|
423
|
+
`kernel.use()` only registers, `initPluginWithTimeout` does not catch,
|
|
424
|
+
`bootstrap()` rethrows, and `os serve`'s outer handler prints the message and
|
|
425
|
+
exits `1`. The `throw` is genuinely fatal here, so it needs none of the
|
|
426
|
+
`process.exit(1)` the tenancy guard required for sitting inside a broad `catch`.
|
|
427
|
+
|
|
428
|
+
- b25a116: fix(verify): resolve the enterprise organizations package from the HOST APP (#4700)
|
|
429
|
+
|
|
430
|
+
`bootStack(app, { multiTenant: true })` — and therefore `objectstack verify
|
|
431
|
+
--multi-tenant` — could never load `@objectstack/organizations`. Node ESM
|
|
432
|
+
resolves a bare `import()` against the **importer's own realpath**, which for
|
|
433
|
+
`packages/verify` is inside the framework workspace, while the enterprise
|
|
434
|
+
package is cloud-private and only ever lives in the verified app's
|
|
435
|
+
`node_modules`. Every real host app fell into the catch and was told to
|
|
436
|
+
"Install/link it in this workspace" — about a package it had already installed.
|
|
437
|
+
Same defect class as cloud#1013, which fixed `objectstack serve`; #4699 fixed
|
|
438
|
+
that one call site and this issue tracked the two the sweep left behind.
|
|
439
|
+
|
|
440
|
+
**New: `@objectstack/types/node`.** The host-app resolver (`createHostRequire` /
|
|
441
|
+
`createHostImporter`) moved out of `packages/cli/src/utils/import-from-host.ts`
|
|
442
|
+
— where `@objectstack/verify` and the dogfood suite could not import it without
|
|
443
|
+
inverting the dependency direction — into a **node-only subpath export** of
|
|
444
|
+
`@objectstack/types`. One behaviour, one source; the CLI now consumes it and its
|
|
445
|
+
private copy is deleted.
|
|
446
|
+
|
|
447
|
+
It is a subpath and **not** the root export because `@objectstack/types` is a
|
|
448
|
+
dependency of `@objectstack/hono` ("edge-compatible REST API server for
|
|
449
|
+
Cloudflare Workers, Deno, Bun, and Node") and of the plugin layer a `LiteKernel`
|
|
450
|
+
boots on Workers. The root entry reaches zero `node:` builtins, and a Workers
|
|
451
|
+
bundle breaks on `node:module` even when nothing calls it. `tsup` emits the two
|
|
452
|
+
entries as separate self-contained bundles (`splitting: false`), and a test
|
|
453
|
+
walks the root's import graph and fails on the first reachable `node:`
|
|
454
|
+
specifier, so the isolation is enforced rather than merely intended. Same
|
|
455
|
+
arrangement `@objectstack/metadata` already ships for its `./node` subpath.
|
|
456
|
+
|
|
457
|
+
**New: `BootOptions.hostRoot`** (optional, defaults to `process.cwd()`) names
|
|
458
|
+
the app whose `node_modules` supplies those optional packages — for a harness
|
|
459
|
+
booting an app that is not the working directory.
|
|
460
|
+
|
|
461
|
+
**The dogfood multi-org gates had never run.** Two suites probed availability
|
|
462
|
+
with the same bare `import()` and so were **constant-false** — not "false
|
|
463
|
+
because absent" but false by construction, in every environment including the
|
|
464
|
+
cloud CI whose comment claimed it ran them. The #1994 cross-tenant RLS proof and
|
|
465
|
+
the attachments cross-tenant isolation block had therefore never executed while
|
|
466
|
+
the suite reported green (Prime Directive #10, test-suite edition). They now
|
|
467
|
+
resolve like the runtime does, and `OS_TEST_MULTI_ORG_ENABLED=1` declares that a
|
|
468
|
+
run is expected to ship the package — turning a silent skip into a loud failure,
|
|
469
|
+
so a run can no longer pass by quietly not running the gates it exists for.
|
|
470
|
+
|
|
471
|
+
- 02dc076: feat(types,cli,verify)!: 只解析 host app 声明过的包 —— `NODE_PATH` 不再算数,ADR-0093 D5 那道墙从此与启动方式无关 (#4719)
|
|
472
|
+
|
|
473
|
+
**问题:契约写下了,但从没被检查过。** `@objectstack/types/node` 的
|
|
474
|
+
`createHostRequire` 返回一个 CJS `createRequire`,而 CJS 解析认 `NODE_PATH`
|
|
475
|
+
(`Module.globalPaths`)。pnpm 生成的 bin shim 第一件事就是
|
|
476
|
+
`export NODE_PATH=<workspace>/node_modules/.pnpm/node_modules`,于是任何被工作区里
|
|
477
|
+
**任意一个包**传递依赖到的包都能"从 host app 解析成功" —— 跟这个 app 声明了什么毫无关系。
|
|
478
|
+
|
|
479
|
+
实测(cloud `apps/objectos-ee`,当时未声明 `@objectstack/organizations`):
|
|
480
|
+
`pnpm start`(经 shim)boot 成功、插件表里有 `Organizations`、ADR-0093 D5 一声不吭;
|
|
481
|
+
`node node_modules/@objectstack/cli/bin/run.js serve`(不经 shim)则
|
|
482
|
+
`✖ FATAL: tenancy posture 'isolated' was requested…` 并 exit 1。同一个 app、同一份
|
|
483
|
+
`package.json`、同一个 posture,**只因为进程是怎么被拉起来的**,走出两种结果。
|
|
484
|
+
而 D5 的报错一直在教 operator "declare it in the app's package.json" —— 那正是
|
|
485
|
+
CLI 从来没检查过的那件事。
|
|
486
|
+
|
|
487
|
+
**改法:声明即执行。** 解析前先读 `<hostRoot>/package.json`;只有包名出现在
|
|
488
|
+
`dependencies` / `devDependencies` / `optionalDependencies` / `peerDependencies`
|
|
489
|
+
的 **键**里,才去 host 的 `node_modules` 里查它。仅仅"能被解析到"不再算数 ——
|
|
490
|
+
那正是让契约失效的那个偶然。未声明的包退回到 importing package 自身的解析
|
|
491
|
+
(ESM,不认 `NODE_PATH`),框架自有的包加载路径不受影响。
|
|
492
|
+
|
|
493
|
+
**两种失败从此分开报。** 今天它们都塌成同一条 `MODULE_NOT_FOUND`,补救办法却相反:
|
|
494
|
+
|
|
495
|
+
- **未声明** —— 指向"在 app 的 `package.json` 里声明并安装",并说明为什么
|
|
496
|
+
hoisting / `NODE_PATH` 不被接受;
|
|
497
|
+
- **声明了但解析不到** —— 明确说这是**安装**问题(`pnpm install`、生产 prune
|
|
498
|
+
砍掉了它、dist 没构建),别再让人回去重看那份已经写对的 `package.json`。
|
|
499
|
+
|
|
500
|
+
分类经新导出的 `hostImportFailureKind(err)` 暴露给调用方;两种错误都仍带
|
|
501
|
+
`code: 'MODULE_NOT_FOUND'`,`isModuleNotFoundError` 的既有判定不变。
|
|
502
|
+
|
|
503
|
+
**BREAKING — 哪类部署会从假绿变红,以及怎么修。**
|
|
504
|
+
|
|
505
|
+
1. **靠 hoisting 苟着的部署。** 一个 app 请求了 walled tenancy posture
|
|
506
|
+
(`OS_TENANCY_POSTURE=group` / `isolated` 或 `OS_MULTI_ORG_ENABLED=1`)、
|
|
507
|
+
却没在自己的 `package.json` 里声明 `@objectstack/organizations`,过去经 pnpm
|
|
508
|
+
shim 启动能正常 boot —— 现在会命中 ADR-0093 D5 并 exit 1。
|
|
509
|
+
**修法:在那个 app 的 `package.json` 里声明该依赖并安装。**
|
|
510
|
+
这些部署本来就在未声明状态下运行,红的是一直存在的事实,不是新引入的故障:
|
|
511
|
+
同一个 app 不经 shim 启动今天就已经是 exit 1。
|
|
512
|
+
(同样适用于 `@objectstack/service-ai` / `@objectstack/service-ai-studio`,以及
|
|
513
|
+
`bootStack({ multiTenant: true })`、dogfood 的 enterprise 门。)
|
|
514
|
+
|
|
515
|
+
2. **`createHostImporter` 的签名变了**,因为它现在需要 host 的**根目录**才能读到
|
|
516
|
+
那份 manifest,而一个 `NodeRequire` 无法被问出它锚在哪里:
|
|
517
|
+
|
|
518
|
+
```diff
|
|
519
|
+
- createHostImporter(createHostRequire(hostRoot))
|
|
520
|
+
+ createHostImporter(hostRoot) // 省略参数 = process.cwd(),同旧默认
|
|
521
|
+
```
|
|
522
|
+
|
|
523
|
+
`createHostRequire` 本身保持不变,仍然导出。
|
|
524
|
+
|
|
525
|
+
新增导出(`@objectstack/types/node`):`HOST_DECLARATION_FIELDS`、
|
|
526
|
+
`HostDeclarationField`、`HostDeclaration`、`readHostDeclaration`、
|
|
527
|
+
`isDeclaredByHost`、`packageNameFromSpecifier`、`HostImportFailureKind`、
|
|
528
|
+
`HOST_IMPORT_FAILURE_KIND`、`hostImportFailureKind`。
|
|
529
|
+
|
|
530
|
+
- 030125b: feat(objectql)!: `init()` refuses to boot when a data driver fails to connect (#3741)
|
|
531
|
+
|
|
532
|
+
`ObjectQLEngine.init()` wrapped every driver's `connect()` in a try/catch, logged
|
|
533
|
+
one error line, and carried on. A server whose database was unreachable therefore
|
|
534
|
+
"started successfully" — health endpoints could even stay green — and then failed
|
|
535
|
+
every request with an error that reads nothing like _the database is down_. The
|
|
536
|
+
warning it printed (`Operations may recover via lazy reconnection or fail at query
|
|
537
|
+
time`) was half fiction: grep the repo and no reconnection exists in `driver-sql`
|
|
538
|
+
or `driver-mongodb`, so only the "fail at query time" half was ever real. The
|
|
539
|
+
caller made it worse — `ObjectQLPlugin.start()` runs `syncRegisteredSchemas()`
|
|
540
|
+
immediately after `init()`, issuing DDL against a driver that isn't there.
|
|
541
|
+
|
|
542
|
+
The structural half of the bug was worse than the operational one: the catch
|
|
543
|
+
removed a driver's ability to **refuse startup at all**. Any fatal startup check —
|
|
544
|
+
licence, server version, incompatible configuration, missing capability, not just
|
|
545
|
+
an unreachable socket — is expressed by throwing from `connect()`, and every one
|
|
546
|
+
of them was silently downgraded to a runtime error. That is why driver-mongodb's
|
|
547
|
+
multi-tenancy guard (#3724 / #3734) had to be hoisted into its constructor.
|
|
548
|
+
|
|
549
|
+
- `init()` now **throws** `DriverConnectError` (`code: 'ERR_DRIVER_CONNECT'`)
|
|
550
|
+
when any boot-registered driver's `connect()` rejects, aborting kernel
|
|
551
|
+
bootstrap. It still attempts every driver first, so one failed boot names all
|
|
552
|
+
of them. The message is self-contained — each failed driver and its cause —
|
|
553
|
+
because the CLI prints `error.message` alone; the first cause is also attached
|
|
554
|
+
as `error.cause`. Exported from both `@objectstack/objectql` and
|
|
555
|
+
`@objectstack/objectql/core`.
|
|
556
|
+
- `connect()` is now a supported place for a driver to veto boot. Startup
|
|
557
|
+
validation that needs a live connection (server version, capability probes)
|
|
558
|
+
no longer has to be forced into a constructor.
|
|
559
|
+
- The misleading "lazy reconnection" warning is gone.
|
|
560
|
+
- New escape hatch `OS_ALLOW_DRIVER_CONNECT_FAILURE=1`
|
|
561
|
+
(`resolveAllowDriverConnectFailure()` in `@objectstack/types`) restores the old
|
|
562
|
+
lenient boot, but loudly: a `DEGRADED BOOT` banner names the failed drivers and
|
|
563
|
+
states that they are never retried or reconnected and that every query and
|
|
564
|
+
schema sync routed to them will fail for the process lifetime. The banner goes
|
|
565
|
+
to stderr as well as the logger, because `os serve` swallows all of stdout
|
|
566
|
+
during boot and `Logger` routes `warn` there — logger-only, the one message
|
|
567
|
+
that matters would be invisible in exactly the deployment the flag is for.
|
|
568
|
+
Defaults off.
|
|
569
|
+
|
|
570
|
+
**Migration.** No code or config change is needed for a correctly configured
|
|
571
|
+
deployment — a driver that connected before still connects. A deployment that was
|
|
572
|
+
_silently_ booting without its database now fails the boot instead, with the
|
|
573
|
+
driver name and cause in the error; fix the datasource configuration (typically
|
|
574
|
+
`OS_DATABASE_URL`, credentials, or network reachability). To keep booting without
|
|
575
|
+
it — deliberately, and knowing every request that touches it will fail — set
|
|
576
|
+
`OS_ALLOW_DRIVER_CONNECT_FAILURE=1`.
|
|
577
|
+
|
|
578
|
+
- b4b2c7d: fix(rest,runtime,types): the direct-mount package door answers a coded refusal with its own status and code (#8016)
|
|
579
|
+
|
|
580
|
+
**This changes HTTP status codes on a live surface.** Requests to
|
|
581
|
+
`/api/v1/packages` that today come back `500 INTERNAL_ERROR` will come back as
|
|
582
|
+
the refusal they always were — `409 DESTRUCTIVE_CHANGE` for an uninstall that
|
|
583
|
+
would drop data, `400`/`403` for a coded refusal thrown from below. A client
|
|
584
|
+
that keys on `500` to decide "the platform is down, retry later" for these
|
|
585
|
+
routes must key on the `code` instead. No route, path, verb or success body
|
|
586
|
+
changes.
|
|
587
|
+
|
|
588
|
+
`/api/v1/packages` has two HTTP transports. The runtime dispatcher's
|
|
589
|
+
(`packages/runtime/src/domains/packages.ts`) reads a thrown error's own
|
|
590
|
+
`.status` and `.code` and answers with them. The direct-mount REST registrar
|
|
591
|
+
(`packages/rest/src/package-routes.ts`) had **four** catch-alls that answered
|
|
592
|
+
`sendError(res, 500, 'INTERNAL_ERROR', …)` regardless — and that registrar
|
|
593
|
+
mounts _first_ in the production stack, so the status-blind answer was the one
|
|
594
|
+
production actually returned. `packageService.publish`, `packageService.delete`
|
|
595
|
+
and `protocol.deletePackage` all execute inside those blocks, and
|
|
596
|
+
`@objectstack/metadata-protocol` throws coded, status-carrying refusals from
|
|
597
|
+
that call path. So a caller who was **refused** was told the platform had
|
|
598
|
+
**broken**: the wrong class of answer, a retry that cannot succeed, and the one
|
|
599
|
+
field a client can branch on dropped.
|
|
600
|
+
|
|
601
|
+
The four sites now leave through one shared exit. The mapping is not
|
|
602
|
+
reimplemented here — that is how the two doors diverged in the first place. It
|
|
603
|
+
moved to `resolveThrownHttpError` in **`@objectstack/types`** (alongside the
|
|
604
|
+
`sendOk`/`sendError` envelope writer and `looksLikeInternalErrorLeak`, for the
|
|
605
|
+
same reason: it is a property of the HTTP boundary, not of one router), and the
|
|
606
|
+
dispatcher's `HttpDispatcher.errorFromThrown` is now its other caller. It could
|
|
607
|
+
not live in `@objectstack/runtime`: that package depends on `@objectstack/rest`,
|
|
608
|
+
so the import can only point one way.
|
|
609
|
+
|
|
610
|
+
The rule, unchanged from what the dispatcher always applied:
|
|
611
|
+
|
|
612
|
+
- **status** — the producer's `.status`, then `.statusCode` (both spellings are
|
|
613
|
+
produced in this repo), then `400` for a record-validation failure, then the
|
|
614
|
+
caller's fallback.
|
|
615
|
+
- **code** — `VALIDATION_FAILED` for a validation failure, then the thrown
|
|
616
|
+
`.code` **when it is a member of the declared ADR-0112 vocabulary**
|
|
617
|
+
(`StandardErrorCode ∪ ERROR_CODE_LEDGER`), then the code the status derives.
|
|
618
|
+
An unregistered code no longer reaches `error.code` on the dispatcher door
|
|
619
|
+
either; it would have failed envelope parse, which is ADR-0112's closed
|
|
620
|
+
vocabulary working rather than a dialect leaking onto the wire.
|
|
621
|
+
- **the 500 survives** — a throw declaring neither status nor a registered code
|
|
622
|
+
is a genuine fault and still answers `500 INTERNAL_ERROR`.
|
|
623
|
+
|
|
624
|
+
`validation-failure.ts` moved from `@objectstack/runtime` to
|
|
625
|
+
`@objectstack/types` for reachability and is re-exported from its old module
|
|
626
|
+
path; every existing import site is unchanged.
|
|
627
|
+
|
|
628
|
+
Unchanged and deliberately so: this REST door still ships a 5xx message
|
|
629
|
+
verbatim, where the dispatcher withholds one that looks like an internal leak
|
|
630
|
+
(`looksLikeInternalErrorLeak`, #3867). That asymmetry predates this fix and is
|
|
631
|
+
filed separately.
|
|
632
|
+
|
|
633
|
+
- 91cefb8: refactor(types,rest,metadata,analytics): Postgres 的 `"x" of relation "y"` 短语收归一处，三个包不再各修一遍同一个超串洞（#6615）
|
|
634
|
+
|
|
635
|
+
Postgres 把「关系内部某个子对象」的失败写成 `column "label" of relation "sys_team" does not exist`——里面**逐字包含**一句合法的「表不存在」短语 `relation "sys_team" does not exist`，含义却相反：关系正因为存在才被点名。任何对「这句话是不是在说表没了」的正则收紧都消不掉这个匹配，短语确实在里面；唯一的修法是**先问更具体的问题**。所以修的是**顺序**，不是模式。
|
|
636
|
+
|
|
637
|
+
正因为如此，这个短语被分三次教给了这个仓库，分属三个包、三个 PR，其中两次是在别处已经踩过同一个洞之后：`@objectstack/rest` 的 `mapDataError`（#5352）、`@objectstack/service-analytics` 的缺列扣除（#6035 / PR #6346）、`@objectstack/metadata` 的 `MISSING_TABLE.excludes`（#6347 / PR #6613）。本次把它收进 `@objectstack/types`，与 `isUniqueViolationError`（#6250）和 `isModuleNotFoundError`（framework#3265）同一个理由与同一个位置。
|
|
638
|
+
|
|
639
|
+
**两种宽度，故意保留成两个导出。** 三个消费者要的并不是同一条正则，差别也不是随手写的，而是**每个站点哪个方向的误差是安全的**：
|
|
640
|
+
|
|
641
|
+
- `matchMissingColumnOfRelation(message)` —— 严格提取器，锚定 Postgres 的 errmsg 模板 `column "%s" of relation "%s" does not exist`，返回列名。`rest` 用它把 42703 答成 `400 INVALID_FIELD` 而不是 `404`；`service-analytics` 用它在分类前扣除缺列。这两处**过宽**会把真正缺失的表变成硬失败、回退 #5033 刻意保留的宽容，**漏匹配**只是让消息含糊一点——所以必须严格。
|
|
642
|
+
- `isRelationSubObjectPhrase(message)` —— 宽检测器，丢掉 `column` / `[a-z0-9_]+` / `does not exist` 三个锚点：任意子对象、任意带引号标识符、任意判词。`metadata` 用它做排除。这一处**过宽**只会把良性判定变成响亮判定，**漏匹配**却会让 `event_seq` 从 1 重新开始、撞进一张已有行的历史表——方向正好相反。
|
|
643
|
+
|
|
644
|
+
把两者合并成一条正则，无论哪种宽度胜出都会对其中一个调用方是错的；这是卡片记录在案的风险，两个导出即为此而设，理由是承重的而非风格的。仓库里第四份拷贝（`service-analytics` 测试内用于守护 fixture 的那条正则）同时收编：它本是为「两张面孔别对不上」而写，却把断言打在其中一面的私有复述上，因而正是它要防的漂移。
|
|
645
|
+
|
|
646
|
+
行为逐字保持不变：搬进来的两条模式与原站点逐字节相同。`@objectstack/service-analytics` 因此新增一条对 `@objectstack/types` 的依赖边——这是本次唯一的依赖变化，构造上无环（`@objectstack/types` 只依赖 `@objectstack/spec`，后者无仓内依赖），且仓库 73 个包中已有 25 个、16 个 service 中已有 5 个携带同一条边。
|
|
647
|
+
|
|
648
|
+
- d5749d7: refactor(types,rest,services,plugin-sharing): one shared writer for the response envelope, and `error.code` is enforced at compile time (#3973)
|
|
649
|
+
|
|
650
|
+
`BaseResponseSchema` declares one envelope for every REST body the platform
|
|
651
|
+
emits. It declared it once; the code that _wrote_ it was copied per route
|
|
652
|
+
module. After #3843 and #3983 converted the last drifting one, seven modules
|
|
653
|
+
each carried their own two-line `sendOk` / `sendError` pair — so the envelope's
|
|
654
|
+
shape lived in fourteen places rather than one.
|
|
655
|
+
|
|
656
|
+
`pnpm check:route-envelope` proved those seven copies agreed, which is why this
|
|
657
|
+
is a cleanup rather than a bug fix. But a guard proves agreement; it does not
|
|
658
|
+
create it. An eighth module starts by copying the pair again — not
|
|
659
|
+
hypothetically: `share-link-routes.ts` was found already drifting by the
|
|
660
|
+
repo-wide scan, and its drift had broken `client.shareLinks.create()` and
|
|
661
|
+
`.list()` through `unwrapResponse` (#3983).
|
|
662
|
+
|
|
663
|
+
## What moved
|
|
664
|
+
|
|
665
|
+
`sendOk` / `sendError` now live once, in `@objectstack/types`
|
|
666
|
+
(`response-envelope.ts`), and all seven modules import them:
|
|
667
|
+
|
|
668
|
+
| Module |
|
|
669
|
+
| ------------------------------------- |
|
|
670
|
+
| `service-storage/storage-routes.ts` |
|
|
671
|
+
| `service-settings/settings-routes.ts` |
|
|
672
|
+
| `service-datasource/admin-routes.ts` |
|
|
673
|
+
| `rest/external-datasource-routes.ts` |
|
|
674
|
+
| `rest/package-routes.ts` |
|
|
675
|
+
| `service-i18n/i18n-service-plugin.ts` |
|
|
676
|
+
| `plugin-sharing/share-link-routes.ts` |
|
|
677
|
+
|
|
678
|
+
Placement was the open question in #3973, not design. `packages/spec` is
|
|
679
|
+
schemas-only (Prime Directive #2), and the callers span `rest`, four
|
|
680
|
+
`services/*` and one `plugins/*`, which rules out anything depending on them.
|
|
681
|
+
`@objectstack/types` depends on nothing but `@objectstack/spec`, so every caller
|
|
682
|
+
can reach it, and it is already where the repo puts a helper the HTTP boundaries
|
|
683
|
+
share — `looksLikeInternalErrorLeak` (#3867) sits one file over and made the
|
|
684
|
+
same argument first.
|
|
685
|
+
|
|
686
|
+
The builders take a structural `{ status(n), json(body) }`, so the package
|
|
687
|
+
imports no HTTP contract at all: `IHttpResponse` satisfies it, and so does the
|
|
688
|
+
`any`-typed `res` the older modules carry.
|
|
689
|
+
|
|
690
|
+
## `error.code` is now checked by the compiler
|
|
691
|
+
|
|
692
|
+
All seven copies typed the parameter `code: string`. ADR-0112 (#3841) closed the
|
|
693
|
+
vocabulary — `ErrorCode` is `StandardErrorCode ∪ ERROR_CODE_LEDGER` — but an
|
|
694
|
+
invented code was still caught only at runtime, by a conformance suite parsing a
|
|
695
|
+
driven body, i.e. only on routes some test happened to drive.
|
|
696
|
+
|
|
697
|
+
The shared `sendError` types `code` as `ErrorCode`, so an unregistered code now
|
|
698
|
+
fails to compile, at every call site at once:
|
|
699
|
+
|
|
700
|
+
```ts
|
|
701
|
+
sendError(res, 400, "NOT_A_REGISTERED_CODE", "invented");
|
|
702
|
+
// Argument of type '"NOT_A_REGISTERED_CODE"' is not assignable to parameter of type 'ErrorCode'.
|
|
703
|
+
```
|
|
704
|
+
|
|
705
|
+
This cost no call-site churn: every code the seven modules emit was already
|
|
706
|
+
registered.
|
|
707
|
+
|
|
708
|
+
## `extra` is closed at the same place
|
|
709
|
+
|
|
710
|
+
`sendError`'s last parameter is `Pick<ApiError, 'category' | 'httpStatus' |
|
|
711
|
+
'details' | 'requestId'>` — exactly what `ApiErrorSchema` declares beside `code`
|
|
712
|
+
and `message`.
|
|
713
|
+
|
|
714
|
+
It was `Record<string, unknown>` while `settings-routes` still hung `namespace` /
|
|
715
|
+
`key` / `reason` / `fields` beside `code`. Those bodies passed every gate anyway:
|
|
716
|
+
`ApiErrorSchema` is a plain `z.object`, so unknown keys were STRIPPED rather than
|
|
717
|
+
rejected, and `envelopeViolations` inspects only the body's top level —
|
|
718
|
+
conformant _by stripping_ rather than by declaration. #4224 moved that module
|
|
719
|
+
onto `details`, which is what lets the parameter close here. Closing it at the
|
|
720
|
+
shared builder is the part that lasts: an undeclared sibling is now a compile
|
|
721
|
+
error in every module at once, rather than a key that quietly evaporates in
|
|
722
|
+
whichever module reintroduces it.
|
|
723
|
+
|
|
724
|
+
## Nothing changes on the wire
|
|
725
|
+
|
|
726
|
+
The seven pairs were identical modulo the optional `status` and `extra`
|
|
727
|
+
parameters this one unions, and each module's driven conformance suite still
|
|
728
|
+
parses its real bodies against the real spec schemas. One internal call site was
|
|
729
|
+
rewritten: `package-routes` passed `details` positionally and now passes
|
|
730
|
+
`{ details }`, producing the same `error.details` it always did.
|
|
731
|
+
|
|
732
|
+
## The guard got stronger
|
|
733
|
+
|
|
734
|
+
`scripts/check-route-envelope.mjs` counts response write sites per module. A
|
|
735
|
+
module that routes everything through the shared pair builds **none** itself, so
|
|
736
|
+
the seven now declare `0 / 0 / 0` where they used to declare `2 / 1 / 1`, and the
|
|
737
|
+
shared pair is pinned separately at `2 / 1 / 1` so the invariant stays total for
|
|
738
|
+
the surface rather than per-module. What the count asserts is no longer "your two
|
|
739
|
+
builders are the enveloped ones" but "you have no builders" — and a new route
|
|
740
|
+
that hand-rolls a body still moves it off zero and fails.
|
|
741
|
+
|
|
742
|
+
- 129b378: fix(types,rest): one named answer for "which column conflicted" — an index name is never returned as one (#6544)
|
|
743
|
+
|
|
744
|
+
#6250 retired four private "is this a unique violation?" vocabularies into
|
|
745
|
+
`isUniqueViolationError`. It left the harder half of the question behind: the
|
|
746
|
+
import runner's `sanitizeRowError` still carried its own three-dialect regex
|
|
747
|
+
chain, because it does **more** than answer yes/no — it names the offending
|
|
748
|
+
column so the importer can say _"A record with this `email` already exists."_
|
|
749
|
+
This lands that second answer as a shared export and migrates the last private
|
|
750
|
+
copy onto it.
|
|
751
|
+
|
|
752
|
+
**New — `uniqueViolationColumn(error)` in `@objectstack/types`** (`string |
|
|
753
|
+
undefined`), sibling to `isUniqueViolationError` and gated on it, reading the
|
|
754
|
+
same channels one step down the same bounded `cause` chain, plus
|
|
755
|
+
node-postgres' `detail` field.
|
|
756
|
+
|
|
757
|
+
**Its contract, per the maintainer's 2026-08-08 ruling: a value comes back only
|
|
758
|
+
when the identifier the driver printed is determinably a COLUMN.** When a
|
|
759
|
+
dialect names an _index_ instead — MySQL's `Duplicate entry … for key
|
|
760
|
+
'idx_email_unique'`, Postgres' `violates unique constraint "sys_user_email_key"`,
|
|
761
|
+
SQLite's `UNIQUE constraint failed: index 'x'` — the answer is `undefined`,
|
|
762
|
+
never the index name. Callers render this into a form field, and an index name
|
|
763
|
+
mistaken for a column points the user at a field that does not exist, whereas
|
|
764
|
+
`undefined` degrades to generic copy. A **composite** key (`Key (tenant_id,
|
|
765
|
+
email)=(…)`) is `undefined` for the same reason: there is no single offending
|
|
766
|
+
column, and naming the first is the same class of wrong answer.
|
|
767
|
+
|
|
768
|
+
**⚠️ User-visible change on MySQL imports.** MySQL's duplicate-entry message
|
|
769
|
+
names the index and never the column, so the importer no longer names a column
|
|
770
|
+
there: rows that used to read _"A record with this `idx_email_unique` already
|
|
771
|
+
exists."_ — or, on MySQL 8's table-qualified `for key 'sys_user.email'`, a
|
|
772
|
+
plausible-looking _`email`_ that was still an index name — now read **"A record
|
|
773
|
+
with this value already exists."** That is deliberate and is the accepted cost
|
|
774
|
+
of the ruling. The conflict is still recognised as a conflict; only the naming
|
|
775
|
+
narrowed.
|
|
776
|
+
|
|
777
|
+
Three smaller import messages improve in the same move, all previously wrong
|
|
778
|
+
rather than merely vague:
|
|
779
|
+
|
|
780
|
+
- SQLite's expression/partial-index form used to render as _"A record with this
|
|
781
|
+
**index** already exists."_
|
|
782
|
+
- Postgres' expression index used to render the truncated fragment _"A record
|
|
783
|
+
with this **lower(email** already exists."_
|
|
784
|
+
- A Postgres conflict with no `DETAIL:` line used to fall through to the SQL
|
|
785
|
+
backstop and echo the driver's own sentence — index name included — at the
|
|
786
|
+
importer. It now gets the same generic conflict copy, which is also the exact
|
|
787
|
+
wording `mapDataError` puts in the 409 `UNIQUE_VIOLATION` body, so the
|
|
788
|
+
importer and the API say one thing about one condition.
|
|
789
|
+
|
|
790
|
+
Not changed: the NOT NULL branch, the raw-SQL backstop, and every non-conflict
|
|
791
|
+
message, which pass through exactly as before.
|
|
792
|
+
|
|
793
|
+
### Patch Changes
|
|
794
|
+
|
|
795
|
+
- a8940e4: The ADR-0114 D3 mapper (Zod issue codes → the closed `FieldErrorCode` catalog) is now
|
|
796
|
+
`zodIssuesToFields`, exported from `@objectstack/spec` (`@objectstack/spec/api`), and it is
|
|
797
|
+
the ONE implementation of D3's table in the repo (#8124).
|
|
798
|
+
|
|
799
|
+
Why: `fields[].code` is declared as a closed catalog (`FieldErrorCode`, ADR-0114 D2), but
|
|
800
|
+
`@objectstack/types`' `fieldsFromZodIssues` — the helper the runtime `/analytics`,
|
|
801
|
+
`/notifications` and `/automation` entry refusals emit through — passed Zod's own issue
|
|
802
|
+
codes through verbatim. A refusal carrying `unrecognized_keys` / `too_small` did not parse
|
|
803
|
+
against the schema the protocol declares for it, and the same wire slot spoke two
|
|
804
|
+
vocabularies depending on which route served it.
|
|
805
|
+
|
|
806
|
+
What changed on the wire (all three runtime domain routes):
|
|
807
|
+
|
|
808
|
+
- `fields[].code` values are now catalog members: `unrecognized_keys` → `unknown_field`,
|
|
809
|
+
`too_small` → `min_length`/`min_value`/`min_items` (by origin), `too_big` → the `max_*`
|
|
810
|
+
mirrors, enum misses → `invalid_option`, `custom` and any unmapped Zod code →
|
|
811
|
+
`invalid_value`.
|
|
812
|
+
- A rejection behind a `z.union` is expanded per #5014: the union's own entry is followed
|
|
813
|
+
by the branch entries that explain it, so entry count is no longer issue count.
|
|
814
|
+
- Two hand-spelled `unrecognized_keys` literals (the analytics `filters` hint and the
|
|
815
|
+
automation toggle unknown-key refusal) now say `unknown_field`, the catalog member.
|
|
816
|
+
|
|
817
|
+
`@objectstack/rest` re-exports the shared implementation from `rest-server.ts` and its
|
|
818
|
+
behavior is unchanged (its own mapper tests pin that); `fieldsFromZodIssues` keeps its
|
|
819
|
+
signature (plus an optional trailing `input` that upgrades a missing required property from
|
|
820
|
+
`invalid_type` to `required`, per the D3 table) and keeps the `'(body)'` spelling for
|
|
821
|
+
root-level failures.
|
|
822
|
+
|
|
823
|
+
- 2e836de: chore(packaging): CHANGELOG.md ships in every npm tarball (#4261)
|
|
824
|
+
|
|
825
|
+
The AGENTS.md post-task checklist requires breaking changesets to carry their
|
|
826
|
+
FROM → TO migration because "this text ships to consumers as `CHANGELOG.md`
|
|
827
|
+
inside the npm package and is what an upgrading agent greps after the tombstone
|
|
828
|
+
error." That delivery path was severed for 68 of the 69 publishable packages:
|
|
829
|
+
npm packs `package.json` / `README*` / `LICENSE*` unconditionally but — unlike
|
|
830
|
+
older npm versions — not `CHANGELOG.md`, and the canonical
|
|
831
|
+
`"files": ["dist", "README.md"]` whitelist never named it. Measured on npm
|
|
832
|
+
10.9.7: `npm pack --dry-run` on `@objectstack/types` shipped 3 files while its
|
|
833
|
+
70KB `CHANGELOG.md` stayed behind. Only `@objectstack/spec` listed it
|
|
834
|
+
explicitly.
|
|
835
|
+
|
|
836
|
+
The tombstone-error scenario is precisely the one where the repo is out of
|
|
837
|
+
reach — the upgrading agent has `node_modules` and nothing else — so the
|
|
838
|
+
migration text has to ride in the tarball. Every publishable package now
|
|
839
|
+
declares `CHANGELOG.md` in `files`, and the canonical whitelist is
|
|
840
|
+
`["dist", "README.md", "CHANGELOG.md"]`.
|
|
841
|
+
|
|
842
|
+
The other half is the gate: `check:published-files` gains a fifth invariant,
|
|
843
|
+
COMPLETE — a whitelist that fails to cover `CHANGELOG.md` fails the
|
|
844
|
+
always-required lint job, so the next package cannot silently sever the path
|
|
845
|
+
again. `@objectstack/spec`'s per-package EXTRA_ENTRIES exemption dissolves
|
|
846
|
+
into the canonical set.
|
|
847
|
+
|
|
848
|
+
Consumer-visible change: one more file per install (the package's changelog,
|
|
849
|
+
e.g. 70.8KB for `@objectstack/types`), and `grep -r "removed key"
|
|
850
|
+
node_modules/@objectstack/*/CHANGELOG.md` now finds the migration it was
|
|
851
|
+
promised.
|
|
852
|
+
|
|
853
|
+
- 87aca93: fix(datasource)!: a declared datasource that objects bind to must connect, or the boot fails (#3758)
|
|
854
|
+
|
|
855
|
+
`DatasourceConnectionService.handleFailure()` fail-fasted only for an `external`
|
|
856
|
+
datasource with `validation.onMismatch: 'fail'`. Everything else degraded to one
|
|
857
|
+
`warn` line — including the case the D2 auto-connect gate itself flags as having
|
|
858
|
+
**no fallback path**: a datasource that objects bind to explicitly via
|
|
859
|
+
`object.datasource`. Those objects never fall through to the `default` driver;
|
|
860
|
+
`engine.getDriver` throws `Datasource 'x' is not registered` for them.
|
|
861
|
+
|
|
862
|
+
So an app declaring `datasource: 'analytics'` with 20 objects bound to it, booted
|
|
863
|
+
against a wrong `ANALYTICS_URL`, started clean and exited zero — and then failed
|
|
864
|
+
every read and write of those 20 objects with an error that reads nothing like
|
|
865
|
+
_the analytics database is unreachable_. The rest of the app worked, which made it
|
|
866
|
+
**harder** to locate than a total outage: it looks like "some pages are broken",
|
|
867
|
+
not like a misconfigured datasource. This is the same decision #3741/#3751 fixed
|
|
868
|
+
one layer up in `ObjectQLEngine.init()`; the boundary here was still drawn in the
|
|
869
|
+
old place.
|
|
870
|
+
|
|
871
|
+
- **Fail-fast is now keyed on "no fallback path", not on `onMismatch` alone.** At
|
|
872
|
+
the `declared-auto` (boot) trigger, a connect failure aborts the boot when the
|
|
873
|
+
datasource is `external` + `onMismatch: 'fail'` **or** when ≥1 object binds to
|
|
874
|
+
it explicitly. `autoConnect: true` with nothing bound stays lenient — that is
|
|
875
|
+
"connect it if you can", and nothing declares a dependency on it. The
|
|
876
|
+
runtime-admin create/update and boot-rehydration triggers are unchanged and
|
|
877
|
+
still always degrade: a UI action must never brick a running server.
|
|
878
|
+
- **Every failure mode counts**, not just an unreachable socket: an unresolvable
|
|
879
|
+
`external.credentialsRef` (D3) and an unsupported `driver` leave the bound
|
|
880
|
+
objects exactly as dead, so they take the same verdict.
|
|
881
|
+
- **The error names the bound objects** (up to 10, then `+N more`) alongside the
|
|
882
|
+
underlying cause, so the message points at the real problem instead of just the
|
|
883
|
+
datasource name. The service already receives the list for post-connect
|
|
884
|
+
`syncObjectSchema`.
|
|
885
|
+
- **`connectDeclared()` attempts every gated datasource before throwing**, and
|
|
886
|
+
aggregates, so one failed boot reports all the misconfigured ones rather than
|
|
887
|
+
one per restart — the same shape as `ObjectQLEngine.init()`'s
|
|
888
|
+
`DriverConnectError`.
|
|
889
|
+
- **The escape hatch is shared with the engine guard**:
|
|
890
|
+
`OS_ALLOW_DRIVER_CONNECT_FAILURE=1` now also covers this path (and covers
|
|
891
|
+
`onMismatch: 'fail'`, which previously had no opt-out). The operator intent is
|
|
892
|
+
identical — "I know the database is unreachable, boot anyway" — and two flags
|
|
893
|
+
would only guarantee one of them gets missed. When set, boot continues and a
|
|
894
|
+
`DEGRADED BOOT` banner goes to stderr as well as the logger, because `os serve`
|
|
895
|
+
swallows stdout during boot. `emitDegradedBootBanner` moved to
|
|
896
|
+
`@objectstack/types` so both call sites share one implementation;
|
|
897
|
+
`@objectstack/objectql` re-exports it unchanged.
|
|
898
|
+
|
|
899
|
+
ADR-0062 D5 is amended with the new criterion and the shared flag.
|
|
900
|
+
|
|
901
|
+
**Migration.** No change for a correctly configured deployment — a datasource that
|
|
902
|
+
connected before still connects. A deployment that was _silently_ booting with a
|
|
903
|
+
dead, explicitly-bound datasource now fails the boot instead, naming the
|
|
904
|
+
datasource, the cause, and the objects that depend on it; fix the datasource
|
|
905
|
+
configuration. To keep booting without it — deliberately, knowing every request
|
|
906
|
+
touching those objects will fail — set `OS_ALLOW_DRIVER_CONNECT_FAILURE=1`.
|
|
907
|
+
|
|
908
|
+
- c20b875: **Correct the stale premise left behind by #4012: the degraded-boot stderr copy
|
|
909
|
+
survives the operator's LOG LEVEL, not `os serve`'s boot-quiet window.**
|
|
910
|
+
|
|
911
|
+
`emitDegradedBootBanner` writes the `OS_ALLOW_DRIVER_CONNECT_FAILURE` banner to
|
|
912
|
+
stderr in addition to `logger.warn`, and every comment and test name explaining
|
|
913
|
+
why cited the same reason: `os serve` swallowed all of stdout while the kernel
|
|
914
|
+
booted, and `Logger` routes `warn` to stdout. #4012 fixed that — the boot window
|
|
915
|
+
now buffers and replays `warn`-and-above — which retires the _stated_
|
|
916
|
+
justification for a duplicate that is nonetheless still load-bearing:
|
|
917
|
+
|
|
918
|
+
`Logger.write()` returns before touching a stream when the record is below
|
|
919
|
+
`config.level`, so at `--log-level error`, `fatal` or `silent` the banner's
|
|
920
|
+
`logger.warn` reaches **no** stream at all. A production host at `error` is
|
|
921
|
+
exactly the deployment this escape hatch exists for, and exactly where a
|
|
922
|
+
logger-only banner would vanish. Removing the stderr copy on the strength of
|
|
923
|
+
#4012 would therefore have been a regression — so this documents the reason that
|
|
924
|
+
is still true, in the places someone would read before deleting it:
|
|
925
|
+
`degraded-boot.ts`, the engine's emit site, and all three parity tests
|
|
926
|
+
(objectql, runtime, service-datasource), which are renamed off "which `os serve`
|
|
927
|
+
boot-quiet cannot swallow" to "which the operator log level cannot filter away".
|
|
928
|
+
|
|
929
|
+
The objectql parity test now proves the claim instead of asserting around it: it
|
|
930
|
+
drives a **real** `ObjectLogger` at `level: 'error'` and requires the banner on
|
|
931
|
+
stderr _and_ nothing on stdout. Set the level to `warn` and it fails — so the
|
|
932
|
+
test is pinned to the level filter rather than passing for any reason.
|
|
933
|
+
|
|
934
|
+
Also corrected in the same sweep, all comment-only, all previously overstating
|
|
935
|
+
what #4012 had not yet fixed:
|
|
936
|
+
|
|
937
|
+
- the automation wiring summary (`format.ts`, `serve.ts`, its test) claimed the
|
|
938
|
+
boot window swallowed the engine's binding warnings. Its real justification is
|
|
939
|
+
stronger and unchanged: a flow that silently fails to arm emits **no** log line
|
|
940
|
+
at any level, so binding state has to be read off the live engine — absence of
|
|
941
|
+
a warning was never evidence of a bound flow.
|
|
942
|
+
- the seed summary (`seed-summary.ts`, `format.ts`, its test) and `AppPlugin`'s
|
|
943
|
+
seed-outcome note attributed the silence to the boot window; the operative
|
|
944
|
+
gate is that `SeedLoader`'s result logs are `info`, under the default `warn`.
|
|
945
|
+
|
|
946
|
+
No behavior changes.
|
|
947
|
+
|
|
948
|
+
- 32d3800: fix(driver-sql): bound a connection attempt at 10s, and correct the "no reconnection" claim (#3769, #3759)
|
|
949
|
+
|
|
950
|
+
Two related corrections, both from measuring what #3741/#3751/#3765 had only asserted.
|
|
951
|
+
|
|
952
|
+
**The claim was wrong.** #3751 and #3765 shipped several statements that drivers
|
|
953
|
+
never reconnect — "there is no lazy reconnection", "NOT retried and NOT
|
|
954
|
+
reconnected", "stays disconnected for the process lifetime". Measured, both
|
|
955
|
+
drivers recover on their own:
|
|
956
|
+
|
|
957
|
+
- driver-mongodb: killing a real `mongod` and restarting it on the same port,
|
|
958
|
+
the _same_ driver instance served the next write successfully (13ms), with no
|
|
959
|
+
reconnect call from us — the official driver's topology monitor handles it.
|
|
960
|
+
- driver-sql: a knex/pg pool is not poisoned by an outage. Its error tracks live
|
|
961
|
+
server state (`ECONNREFUSED` while down → a handshake error once a listener is
|
|
962
|
+
back → `ECONNREFUSED` again), i.e. every acquire opens a fresh connection.
|
|
963
|
+
`storage-driver.ts` also configures `pool.min: 0`, so no stale idle
|
|
964
|
+
connections are held.
|
|
965
|
+
|
|
966
|
+
The original reasoning grepped this repo for `reconnect`, found nothing, and
|
|
967
|
+
concluded recovery does not happen — but the recovery lives in the client
|
|
968
|
+
libraries, not in our code. The claims are now corrected in `DriverConnectError`,
|
|
969
|
+
the `DEGRADED BOOT` banner, `resolveAllowDriverConnectFailure`'s docs, and the
|
|
970
|
+
drivers / self-hosting pages.
|
|
971
|
+
|
|
972
|
+
**Fail-fast at boot is unchanged and still correct** — the reason is just
|
|
973
|
+
different. It is not that the connection can never return; it is that the _boot
|
|
974
|
+
sequence_ never re-runs. A driver that missed `init()` also missed
|
|
975
|
+
`syncRegisteredSchemas()`, so its tables can simply not exist even after the
|
|
976
|
+
database comes back. The banner now says that.
|
|
977
|
+
|
|
978
|
+
**The real defect underneath.** `SqlDriver` passed its config to knex untouched,
|
|
979
|
+
so a database endpoint that accepts TCP but never completes the handshake — an
|
|
980
|
+
overloaded instance, a half-open firewall, a load balancer mid-failover — made
|
|
981
|
+
every query wait out tarn's 30s default, then fail with `Timeout acquiring a
|
|
982
|
+
connection. The pool is probably full`, pointing an operator at pool sizing
|
|
983
|
+
instead of the network. With a small `pool.max` a few such queries saturate the
|
|
984
|
+
pool and everything else queues.
|
|
985
|
+
|
|
986
|
+
`SqlDriver` now defaults `pool.createTimeoutMillis` to **10s**, matching
|
|
987
|
+
driver-mongodb's existing `connectTimeoutMS ?? 10_000` so both drivers give up on
|
|
988
|
+
an unreachable server at the same point. A host that sets its own
|
|
989
|
+
`createTimeoutMillis` is left alone.
|
|
990
|
+
|
|
991
|
+
**Migration.** None for a healthy datasource. A deployment that deliberately
|
|
992
|
+
relies on connection establishment taking longer than 10s (a slow cross-region
|
|
993
|
+
replica) should set `pool.createTimeoutMillis` explicitly on its `SqlDriver`
|
|
994
|
+
config.
|
|
995
|
+
|
|
996
|
+
Not fixed here, tracked in #3769: knex still reports the bounded wait as "the
|
|
997
|
+
pool is probably full". An accurate message needs a dialect-specific connect
|
|
998
|
+
timeout (pg's `connectionTimeoutMillis`), which changes the shape of `connection`
|
|
999
|
+
and would regress the startup banner's URL display.
|
|
1000
|
+
|
|
1001
|
+
- f598aa8: Withhold the Postgres and bare-SQLite phrasings of a driver failure from HTTP error bodies
|
|
1002
|
+
|
|
1003
|
+
`looksLikeInternalErrorLeak` recognised SQLite's `SQLITE_ERROR: no such table: sys_metadata`
|
|
1004
|
+
but not the Postgres phrasing of the same condition, `relation "sys_metadata" does not exist`.
|
|
1005
|
+
The result was that one failure disclosed a physical table name or not depending on which
|
|
1006
|
+
engine was underneath, from every boundary that applies the predicate — `HttpDispatcher.error`,
|
|
1007
|
+
the declarative endpoint executor, the dispatcher plugin, the direct-mount package door and the
|
|
1008
|
+
Hono auth-config route.
|
|
1009
|
+
|
|
1010
|
+
The predicate now also recognises, for the engines this repo actually runs:
|
|
1011
|
+
|
|
1012
|
+
- Postgres `relation "…" does not exist` and `column "…" does not exist` (42P01/42703), which
|
|
1013
|
+
covers the `… of relation "…"` sub-object family as a superstring;
|
|
1014
|
+
- Postgres `permission denied for table|relation|sequence|database …` (42501);
|
|
1015
|
+
- SQLite/libsql `no such table:` / `no such column:` in their bare, un-prefixed form.
|
|
1016
|
+
|
|
1017
|
+
Each phrasing is anchored on the driver's own template — a quoted identifier, or the trailing
|
|
1018
|
+
colon — never on the bare tail, so ordinary business messages such as "user does not exist" are
|
|
1019
|
+
still returned to the caller unchanged. The predicate is applied only where the outcome is
|
|
1020
|
+
already a 5xx, and the full text still reaches the server log and the error reporter.
|
|
1021
|
+
|
|
1022
|
+
- 08f93bc: fix(auth): `organization/create` gates on the authoritative `OS_TENANCY_POSTURE`, not the demoted `OS_MULTI_ORG_ENABLED` (#5233)
|
|
1023
|
+
|
|
1024
|
+
A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
|
|
1025
|
+
`group`), legacy boolean unset — mounted the entire organization wall and still
|
|
1026
|
+
answered `403 Creating additional organizations is disabled on this deployment.`
|
|
1027
|
+
to `POST /api/v1/auth/organization/create`. Org-less users had no way to create
|
|
1028
|
+
their workspace, so the guided "Create your workspace" path was a dead end.
|
|
1029
|
+
|
|
1030
|
+
ADR-0105 D1 made `OS_TENANCY_POSTURE` the canonical knob and demoted
|
|
1031
|
+
`OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
|
|
1032
|
+
Two sites in `AuthManager` kept reading the demoted boolean directly, so both
|
|
1033
|
+
reported "single-org" on a deployment that had asked for a wall and got one:
|
|
1034
|
+
|
|
1035
|
+
- `organizationHooks.beforeCreateOrganization` — the 403 above. It now judges
|
|
1036
|
+
`postureEnforcesWall(resolveTenancyPosture())`, matching the knob `serve.ts`'s
|
|
1037
|
+
own ADR-0093 D5 boot guard keys on. Intent is unchanged (single-org still
|
|
1038
|
+
refuses); only the knob is corrected.
|
|
1039
|
+
- `/auth/config`'s `features.multiOrgEnabled` — its no-tenancy-service fallback
|
|
1040
|
+
read the same boolean. It now falls back to the resolved posture, so a lean
|
|
1041
|
+
embedding advertises the capability its own gate allows.
|
|
1042
|
+
|
|
1043
|
+
**No configuration change is needed anywhere.** Deployments that set only
|
|
1044
|
+
`OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
|
|
1045
|
+
falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
|
|
1046
|
+
workaround people used to unblock themselves stays valid. Deployments that set
|
|
1047
|
+
only `OS_TENANCY_POSTURE` can now drop the redundant boolean.
|
|
1048
|
+
|
|
1049
|
+
`resolveMultiOrgEnabled()`'s doc comment in `@objectstack/types` — which still
|
|
1050
|
+
instructed "the auth manager's `/auth/config` feature flag and org-create guard
|
|
1051
|
+
… MUST call this", written before the demotion — now says the opposite: ask the
|
|
1052
|
+
posture, and never gate on this boolean. Its behaviour is unchanged.
|
|
1053
|
+
|
|
1054
|
+
- 9881074: fix(batch): the background walks seek instead of counting, so they stop skipping rows (#4363)
|
|
1055
|
+
|
|
1056
|
+
#4363 made a single paged read a partition of its result set. It could not make
|
|
1057
|
+
a _walk_ one: seven background scans paged with a growing `offset` while writing
|
|
1058
|
+
to the very rows they were reading, and an offset counts into a set those writes
|
|
1059
|
+
are changing. Rows slide past the cursor and are never visited.
|
|
1060
|
+
|
|
1061
|
+
That is not a slow page in any of these — it is a wrong answer wearing the shape
|
|
1062
|
+
of a clean run:
|
|
1063
|
+
|
|
1064
|
+
- **`rebuildApproverIndex`** built its desired state by walking
|
|
1065
|
+
`sys_approval_request WHERE status = 'pending'` with no `orderBy` at all, then
|
|
1066
|
+
**deleted** every index row that state did not explain. A skipped request
|
|
1067
|
+
meant an approver silently dropped from someone's queue. (The loop beside it
|
|
1068
|
+
ordered by `created_at` — not unique, so its pages were never a partition
|
|
1069
|
+
either.)
|
|
1070
|
+
- **`verifyFileReferences`** decides which files nothing references. A record it
|
|
1071
|
+
never visits is reported as an unreferenced file.
|
|
1072
|
+
- **`backfillFileReferences`** and the **pinyin companion backfill** rewrite
|
|
1073
|
+
each row they read, so their own writes were shifting the set out from under
|
|
1074
|
+
the cursor. Records were left unconverted and unsearchable by a run that
|
|
1075
|
+
reported success.
|
|
1076
|
+
- **`scanValueShapes`** exists to vouch that no stored value is off-shape, and
|
|
1077
|
+
it opens a migration gate on that evidence.
|
|
1078
|
+
|
|
1079
|
+
All of them now go through `keysetWalk` (`@objectstack/types`): order by a
|
|
1080
|
+
unique key, and seek past the last one instead of counting from the start. A
|
|
1081
|
+
row's key does not move when the row is updated, and cannot be shifted when
|
|
1082
|
+
another is deleted, so the walk is stable under exactly the mutation these
|
|
1083
|
+
functions perform. It is also O(n) rather than O(n²/page) — measured on
|
|
1084
|
+
Postgres over 2M rows, deep pages cost ~1.1 s by offset against ~0.09 s by seek.
|
|
1085
|
+
|
|
1086
|
+
One deliberate non-conversion: the REST **export** stream keeps its offset. It
|
|
1087
|
+
honors a caller-chosen sort, and a keyset walk would have to re-order the export
|
|
1088
|
+
by `id` to seek — changing what the user asked for to fix a cost. Its pages are
|
|
1089
|
+
already a partition since #4363; only the depth cost remains.
|
|
1090
|
+
|
|
1091
|
+
`keysetWalk` merges the cursor with `$and` rather than spreading it into the
|
|
1092
|
+
caller's filter, so a walk whose own `where` constrains the key column
|
|
1093
|
+
(`{ id: { $in: [...] } }`) keeps that constraint instead of having it silently
|
|
1094
|
+
overwritten. When a `max` cap is set it reads one row beyond the cap to tell
|
|
1095
|
+
"the cap stopped us" from "the source ended exactly there" — without that, a
|
|
1096
|
+
walk that read everything still reports `truncated`, and a caller acting on it
|
|
1097
|
+
goes looking for rows that were never withheld.
|
|
1098
|
+
|
|
1099
|
+
The storage suites' fake engines now **throw** on an `offset` instead of serving
|
|
1100
|
+
one, so the conversion is pinned rather than merely passing.
|
|
1101
|
+
|
|
1102
|
+
- 39eb01b: fix(runtime,cli,types): `os migrate` and the dev runtime now share one `__search` companion schema view (#3955)
|
|
1103
|
+
|
|
1104
|
+
On a zh-locale deployment the dev runtime provisions the hidden `__search`
|
|
1105
|
+
pinyin companion column (ADR-0098) on every eligible object, but the
|
|
1106
|
+
`os migrate plan`/`apply` boot went through `createStandaloneStack`, which
|
|
1107
|
+
never derived the locale-gated pinyin decision from the compiled artifact.
|
|
1108
|
+
Its metadata therefore lacked every companion column, and `migrate plan`
|
|
1109
|
+
reported each live `__search` column of a dev-created database as a
|
|
1110
|
+
destructive orphan — with `--allow-destructive` as the printed remediation,
|
|
1111
|
+
which would have dropped live feature columns.
|
|
1112
|
+
|
|
1113
|
+
- `@objectstack/types`: new `collectConfiguredLocales(i18n)` and
|
|
1114
|
+
`stampSearchPinyinEnabled(i18n)` — the single resolve-and-stamp helper for
|
|
1115
|
+
`OS_SEARCH_PINYIN_ENABLED`. An explicit env value still wins; only a
|
|
1116
|
+
positive locale-derived decision is stamped.
|
|
1117
|
+
- `@objectstack/runtime`: `createStandaloneStack` stamps the decision from
|
|
1118
|
+
the artifact's `i18n` before any plugin constructs a `SchemaRegistry`, and
|
|
1119
|
+
surfaces `i18n` on its result like `requires`/`objects`/`manifest`.
|
|
1120
|
+
- `@objectstack/cli`: the `serve`/`dev` boot now stamps through the same
|
|
1121
|
+
shared helper (behaviour unchanged), so create/serve and plan/apply cannot
|
|
1122
|
+
compute different schema views of the same source tree.
|
|
1123
|
+
|
|
1124
|
+
A fresh CLI-created database is now also born with the same `__search`
|
|
1125
|
+
columns the dev runtime would provision, instead of acquiring them on the
|
|
1126
|
+
next dev boot.
|
|
1127
|
+
|
|
1128
|
+
- 694c350: fix(drivers): a `conflictKeys` upsert with no backing unique index refuses legibly on **Postgres** too, not only SQLite (#8567)
|
|
1129
|
+
|
|
1130
|
+
`SqlDriver.upsert` recognised "the `ON CONFLICT` target is not backed by a
|
|
1131
|
+
PRIMARY KEY or UNIQUE index" on **SQLite only** (#8445). `driver-sql` serves
|
|
1132
|
+
three dialects, so on Postgres the raw driver error still escaped: `mapDataError`
|
|
1133
|
+
fell through to its default branch and served the thrown message as the whole
|
|
1134
|
+
response body — and that message is the **statement**, with no `code` for any
|
|
1135
|
+
client to branch on.
|
|
1136
|
+
|
|
1137
|
+
**What a Postgres caller got, and now gets.** Measured against a real
|
|
1138
|
+
PostgreSQL 16.13 through the same knex + `pg` path the driver uses:
|
|
1139
|
+
|
|
1140
|
+
```
|
|
1141
|
+
before: code=42P10 status=undefined
|
|
1142
|
+
message=insert into "plain" ("email", "id", "title") values ($1, $2, $3)
|
|
1143
|
+
on conflict ("email") do update set "title" = excluded."title"
|
|
1144
|
+
- there is no unique or exclusion constraint matching the ON CONFLICT specification
|
|
1145
|
+
|
|
1146
|
+
after: code=VALIDATION_ERROR status=400
|
|
1147
|
+
message=Cannot upsert into "plain" on conflict keys ("email"): no PRIMARY KEY or
|
|
1148
|
+
UNIQUE index backs them, … Fix by declaring the column(s) "unique: true" …
|
|
1149
|
+
```
|
|
1150
|
+
|
|
1151
|
+
The accept/reject set does not move: the same upserts fail, they fail legibly.
|
|
1152
|
+
The server's own sentence is preserved on the error's `cause`, which no error
|
|
1153
|
+
mapper puts on the wire, so an operator debugging the table keeps the ground
|
|
1154
|
+
truth while the caller stops receiving SQL text.
|
|
1155
|
+
|
|
1156
|
+
**One clause of the refusal wording changed, on both faces.** "…and SQLite
|
|
1157
|
+
refuses the statement" is now "…and **the database** refuses the statement".
|
|
1158
|
+
Once recognition covers Postgres, naming SQLite points a Postgres operator at
|
|
1159
|
+
the wrong engine. `driver-turso`'s remote-face copy moved in the same commit —
|
|
1160
|
+
the two are held word-for-word identical (#5240) by #8568's cross-face parity
|
|
1161
|
+
pin. No other sentence of the refusal changed.
|
|
1162
|
+
|
|
1163
|
+
**Recognition is now a named, shared predicate.**
|
|
1164
|
+
`isUnbackedConflictTargetError` is exported from `@objectstack/types` beside
|
|
1165
|
+
`isUniqueViolationError`, carrying one measured message limb per dialect that
|
|
1166
|
+
can raise the condition. ⚠️ It is deliberately a **separate** predicate:
|
|
1167
|
+
`isUniqueViolationError` answers the opposite condition (an index exists and the
|
|
1168
|
+
row violated it), and a merged one would report a working constraint as a
|
|
1169
|
+
missing one.
|
|
1170
|
+
|
|
1171
|
+
**MySQL is unaffected, by measurement rather than omission.** knex compiles
|
|
1172
|
+
`onConflict(...).merge(...)` on that dialect to `ON DUPLICATE KEY UPDATE`, which
|
|
1173
|
+
takes no conflict target — the named keys never leave the process, so the server
|
|
1174
|
+
is never asked to find an index for them and the condition cannot arise. The
|
|
1175
|
+
compiled statement is pinned; the live MySQL cell is reported as un-run rather
|
|
1176
|
+
than passing vacuously.
|
|
1177
|
+
|
|
1178
|
+
- 88f9d94: fix(types,rest): one named unique-violation predicate — a MySQL conflict is 409 UNIQUE_VIOLATION, not 500 (#6250)
|
|
1179
|
+
|
|
1180
|
+
**On MySQL, every unique-constraint conflict came back as `500 INTERNAL_ERROR`.**
|
|
1181
|
+
The API contract registers `UNIQUE_VIOLATION` as a 409 code
|
|
1182
|
+
(`packages/spec/src/api/error-code-ledger.zod.ts`), so a front end had no way to
|
|
1183
|
+
tell "this email is already taken" from "the server fell over" — no retry advice,
|
|
1184
|
+
no field to point at, and a 5xx in the operator's dashboards for what is an
|
|
1185
|
+
ordinary client outcome. SQLite and Postgres deployments never saw it, which is
|
|
1186
|
+
why it survived: their conflict prose happens to contain the words the mapping
|
|
1187
|
+
looked for.
|
|
1188
|
+
|
|
1189
|
+
**Cause: the conflict verdict was nested inside a leak heuristic.** REST's 409
|
|
1190
|
+
branch lived inside the true-branch of `looksLikeInternalErrorLeak()`, keyed on
|
|
1191
|
+
the substrings `unique constraint` / `unique violation`. MySQL says
|
|
1192
|
+
`ER_DUP_ENTRY: Duplicate entry '…' for key '…'`, which matches no limb of that
|
|
1193
|
+
heuristic, so the conflict never reached the `if` at all and fell out of the
|
|
1194
|
+
terminal `UNCLASSIFIED_FAULT`. Two unrelated questions — "is this a conflict?"
|
|
1195
|
+
and "would echoing this text leak internals?" — had been fused into one, and
|
|
1196
|
+
MySQL is where they disagree.
|
|
1197
|
+
|
|
1198
|
+
Measured on the previous release, through the real error mapper:
|
|
1199
|
+
|
|
1200
|
+
```
|
|
1201
|
+
mysql, bare message 500 INTERNAL_ERROR → 409 UNIQUE_VIOLATION
|
|
1202
|
+
mysql, knex-wrapped SQL 500 DATABASE_ERROR → 409 UNIQUE_VIOLATION
|
|
1203
|
+
postgres, SQLSTATE only 500 INTERNAL_ERROR → 409 UNIQUE_VIOLATION
|
|
1204
|
+
sqlite, message 409 UNIQUE_VIOLATION (unchanged)
|
|
1205
|
+
postgres, message 409 UNIQUE_VIOLATION (unchanged)
|
|
1206
|
+
```
|
|
1207
|
+
|
|
1208
|
+
So the hole was never MySQL-only: the mapping read one of the two channels
|
|
1209
|
+
drivers use. A Postgres error carrying SQLSTATE `23505` with unremarkable prose
|
|
1210
|
+
was a 500 as well.
|
|
1211
|
+
|
|
1212
|
+
**New: `isUniqueViolationError(error)`, exported from `@objectstack/types`.** One
|
|
1213
|
+
named predicate replaces the substring test, reading every channel a driver
|
|
1214
|
+
uses — `code` (`23505` / `ER_DUP_ENTRY` / `SQLITE_CONSTRAINT_UNIQUE`), `errno`
|
|
1215
|
+
(`1062`), the message, and one step down the `cause` chain that pool and
|
|
1216
|
+
query-builder layers wrap with. Its vocabulary is the union of the four
|
|
1217
|
+
hand-written copies the repo already carried, so routing REST through it cannot
|
|
1218
|
+
narrow any verdict clients rely on today; an unrecognised error is never a
|
|
1219
|
+
conflict, because a false 409 tells an SDK not to retry and points the user at a
|
|
1220
|
+
value that is fine.
|
|
1221
|
+
|
|
1222
|
+
**The internal-leak classifier is byte-identical.** The fix hoists the conflict
|
|
1223
|
+
question out of it rather than widening its criteria, so nothing else it guards
|
|
1224
|
+
is reclassified as safe-to-expose. And the 409 body is fixed text: MySQL embeds
|
|
1225
|
+
the offending user data in its message (`Duplicate entry 'a@b.com' …`) and
|
|
1226
|
+
Postgres the index and column names, none of which reaches the client. The full
|
|
1227
|
+
driver text still reaches the server log.
|
|
1228
|
+
|
|
1229
|
+
No action needed. Clients that already handled `409 UNIQUE_VIOLATION` on SQLite
|
|
1230
|
+
and Postgres now receive it on MySQL too.
|
|
1231
|
+
|
|
1232
|
+
- Updated dependencies [50616d9]
|
|
1233
|
+
- Updated dependencies [430dcc2]
|
|
1234
|
+
- Updated dependencies [6a67d7a]
|
|
1235
|
+
- Updated dependencies [333a374]
|
|
1236
|
+
- Updated dependencies [9fe9c1d]
|
|
1237
|
+
- Updated dependencies [3d5c090]
|
|
1238
|
+
- Updated dependencies [e5bd768]
|
|
1239
|
+
- Updated dependencies [08b5a3d]
|
|
1240
|
+
- Updated dependencies [e027b3e]
|
|
1241
|
+
- Updated dependencies [e6ac4bd]
|
|
1242
|
+
- Updated dependencies [c2429b0]
|
|
1243
|
+
- Updated dependencies [445a0c2]
|
|
1244
|
+
- Updated dependencies [d99aeb3]
|
|
1245
|
+
- Updated dependencies [f6609e6]
|
|
1246
|
+
- Updated dependencies [4727eb8]
|
|
1247
|
+
- Updated dependencies [a70358a]
|
|
1248
|
+
- Updated dependencies [0ecc656]
|
|
1249
|
+
- Updated dependencies [06772eb]
|
|
1250
|
+
- Updated dependencies [d4e0809]
|
|
1251
|
+
- Updated dependencies [80334c7]
|
|
1252
|
+
- Updated dependencies [f63cd09]
|
|
1253
|
+
- Updated dependencies [97e7e3c]
|
|
1254
|
+
- Updated dependencies [ce5242c]
|
|
1255
|
+
- Updated dependencies [a7163ea]
|
|
1256
|
+
- Updated dependencies [e6e9379]
|
|
1257
|
+
- Updated dependencies [5823d59]
|
|
1258
|
+
- Updated dependencies [3140f9c]
|
|
1259
|
+
- Updated dependencies [9500ba4]
|
|
1260
|
+
- Updated dependencies [fa3d0cf]
|
|
1261
|
+
- Updated dependencies [af5a224]
|
|
1262
|
+
- Updated dependencies [71f76e1]
|
|
1263
|
+
- Updated dependencies [37b1346]
|
|
1264
|
+
- Updated dependencies [99736a0]
|
|
1265
|
+
- Updated dependencies [fe67e34]
|
|
1266
|
+
- Updated dependencies [fdb4f50]
|
|
1267
|
+
- Updated dependencies [270650f]
|
|
1268
|
+
- Updated dependencies [3aef718]
|
|
1269
|
+
- Updated dependencies [1bd5652]
|
|
1270
|
+
- Updated dependencies [14252d3]
|
|
1271
|
+
- Updated dependencies [7fb436c]
|
|
1272
|
+
- Updated dependencies [879ea13]
|
|
1273
|
+
- Updated dependencies [8828b9e]
|
|
1274
|
+
- Updated dependencies [1ea6bce]
|
|
1275
|
+
- Updated dependencies [c1dcacd]
|
|
1276
|
+
- Updated dependencies [ad303ed]
|
|
1277
|
+
- Updated dependencies [32ccb23]
|
|
1278
|
+
- Updated dependencies [f5a4ef0]
|
|
1279
|
+
- Updated dependencies [2d3e255]
|
|
1280
|
+
- Updated dependencies [a8940e4]
|
|
1281
|
+
- Updated dependencies [7d7521f]
|
|
1282
|
+
- Updated dependencies [5dc4d02]
|
|
1283
|
+
- Updated dependencies [f724f69]
|
|
1284
|
+
- Updated dependencies [98877c9]
|
|
1285
|
+
- Updated dependencies [98877c9]
|
|
1286
|
+
- Updated dependencies [53068c1]
|
|
1287
|
+
- Updated dependencies [ee58392]
|
|
1288
|
+
- Updated dependencies [f16e54e]
|
|
1289
|
+
- Updated dependencies [06be54e]
|
|
1290
|
+
- Updated dependencies [28ad90e]
|
|
1291
|
+
- Updated dependencies [76d74ec]
|
|
1292
|
+
- Updated dependencies [201b31f]
|
|
1293
|
+
- Updated dependencies [e6b1b69]
|
|
1294
|
+
- Updated dependencies [259459d]
|
|
1295
|
+
- Updated dependencies [3f7f14e]
|
|
1296
|
+
- Updated dependencies [e2616e0]
|
|
1297
|
+
- Updated dependencies [6fdc5c6]
|
|
1298
|
+
- Updated dependencies [8b9d71e]
|
|
1299
|
+
- Updated dependencies [05154a1]
|
|
1300
|
+
- Updated dependencies [33f5e23]
|
|
1301
|
+
- Updated dependencies [259af21]
|
|
1302
|
+
- Updated dependencies [f8644c7]
|
|
1303
|
+
- Updated dependencies [306ca50]
|
|
1304
|
+
- Updated dependencies [978fed2]
|
|
1305
|
+
- Updated dependencies [cfc293f]
|
|
1306
|
+
- Updated dependencies [587fc91]
|
|
1307
|
+
- Updated dependencies [de70b42]
|
|
1308
|
+
- Updated dependencies [9b6fe7c]
|
|
1309
|
+
- Updated dependencies [fb3d99b]
|
|
1310
|
+
- Updated dependencies [1986594]
|
|
1311
|
+
- Updated dependencies [6968885]
|
|
1312
|
+
- Updated dependencies [eaed61f]
|
|
1313
|
+
- Updated dependencies [cdfbee2]
|
|
1314
|
+
- Updated dependencies [ad4af62]
|
|
1315
|
+
- Updated dependencies [debe2f6]
|
|
1316
|
+
- Updated dependencies [d44dbfa]
|
|
1317
|
+
- Updated dependencies [29c6c9d]
|
|
1318
|
+
- Updated dependencies [d21c001]
|
|
1319
|
+
- Updated dependencies [ad047d2]
|
|
1320
|
+
- Updated dependencies [8c711fb]
|
|
1321
|
+
- Updated dependencies [f1cc3a3]
|
|
1322
|
+
- Updated dependencies [09e4547]
|
|
1323
|
+
- Updated dependencies [97b0798]
|
|
1324
|
+
- Updated dependencies [474fe39]
|
|
1325
|
+
- Updated dependencies [0bc685a]
|
|
1326
|
+
- Updated dependencies [b949059]
|
|
1327
|
+
- Updated dependencies [2826d1e]
|
|
1328
|
+
- Updated dependencies [be1c52c]
|
|
1329
|
+
- Updated dependencies [c5ff96d]
|
|
1330
|
+
- Updated dependencies [5a84d41]
|
|
1331
|
+
- Updated dependencies [84e7be9]
|
|
1332
|
+
- Updated dependencies [91f4c78]
|
|
1333
|
+
- Updated dependencies [ddc2527]
|
|
1334
|
+
- Updated dependencies [820eff9]
|
|
1335
|
+
- Updated dependencies [a6c3f38]
|
|
1336
|
+
- Updated dependencies [debc23a]
|
|
1337
|
+
- Updated dependencies [0f8ad09]
|
|
1338
|
+
- Updated dependencies [553a47f]
|
|
1339
|
+
- Updated dependencies [43a7a8d]
|
|
1340
|
+
- Updated dependencies [a98085f]
|
|
1341
|
+
- Updated dependencies [20b1a9e]
|
|
1342
|
+
- Updated dependencies [344a22a]
|
|
1343
|
+
- Updated dependencies [4827e91]
|
|
1344
|
+
- Updated dependencies [8d895ff]
|
|
1345
|
+
- Updated dependencies [86f7a20]
|
|
1346
|
+
- Updated dependencies [a3a884d]
|
|
1347
|
+
- Updated dependencies [cfed092]
|
|
1348
|
+
- Updated dependencies [203a449]
|
|
1349
|
+
- Updated dependencies [8f9689f]
|
|
1350
|
+
- Updated dependencies [73f69dc]
|
|
1351
|
+
- Updated dependencies [04c56aa]
|
|
1352
|
+
- Updated dependencies [f6472d7]
|
|
1353
|
+
- Updated dependencies [57a3bb3]
|
|
1354
|
+
- Updated dependencies [b3efeb7]
|
|
1355
|
+
- Updated dependencies [ddd075a]
|
|
1356
|
+
- Updated dependencies [88154be]
|
|
1357
|
+
- Updated dependencies [e8dc61e]
|
|
1358
|
+
- Updated dependencies [9c82146]
|
|
1359
|
+
- Updated dependencies [5f9a987]
|
|
1360
|
+
- Updated dependencies [744b8f5]
|
|
1361
|
+
- Updated dependencies [ac37fc6]
|
|
1362
|
+
- Updated dependencies [2f3e793]
|
|
1363
|
+
- Updated dependencies [4820f55]
|
|
1364
|
+
- Updated dependencies [462d9c4]
|
|
1365
|
+
- Updated dependencies [78caf51]
|
|
1366
|
+
- Updated dependencies [7d21581]
|
|
1367
|
+
- Updated dependencies [37785ed]
|
|
1368
|
+
- Updated dependencies [62a789b]
|
|
1369
|
+
- Updated dependencies [2e284b2]
|
|
1370
|
+
- Updated dependencies [d8e8d9c]
|
|
1371
|
+
- Updated dependencies [789ad63]
|
|
1372
|
+
- Updated dependencies [f2445c9]
|
|
1373
|
+
- Updated dependencies [94e749b]
|
|
1374
|
+
- Updated dependencies [ea1d916]
|
|
1375
|
+
- Updated dependencies [2af1988]
|
|
1376
|
+
- Updated dependencies [1b49eaf]
|
|
1377
|
+
- Updated dependencies [ae31a19]
|
|
1378
|
+
- Updated dependencies [e0f300b]
|
|
1379
|
+
- Updated dependencies [0161c7f]
|
|
1380
|
+
- Updated dependencies [e900015]
|
|
1381
|
+
- Updated dependencies [db02d47]
|
|
1382
|
+
- Updated dependencies [b5bdf48]
|
|
1383
|
+
- Updated dependencies [23338c3]
|
|
1384
|
+
- Updated dependencies [12a19a8]
|
|
1385
|
+
- Updated dependencies [5b843fb]
|
|
1386
|
+
- Updated dependencies [62b6a2f]
|
|
1387
|
+
- Updated dependencies [7e5af5c]
|
|
1388
|
+
- Updated dependencies [5b4780b]
|
|
1389
|
+
- Updated dependencies [a933452]
|
|
1390
|
+
- Updated dependencies [9d1d9c7]
|
|
1391
|
+
- Updated dependencies [8140915]
|
|
1392
|
+
- Updated dependencies [a019e52]
|
|
1393
|
+
- Updated dependencies [e8f8f6c]
|
|
1394
|
+
- Updated dependencies [41dcda3]
|
|
1395
|
+
- Updated dependencies [7b48cf9]
|
|
1396
|
+
- Updated dependencies [b5404f4]
|
|
1397
|
+
- Updated dependencies [64fc6d5]
|
|
1398
|
+
- Updated dependencies [b4487aa]
|
|
1399
|
+
- Updated dependencies [1007379]
|
|
1400
|
+
- Updated dependencies [65ca83a]
|
|
1401
|
+
- Updated dependencies [0bfdf46]
|
|
1402
|
+
- Updated dependencies [947d4f9]
|
|
1403
|
+
- Updated dependencies [f764691]
|
|
1404
|
+
- Updated dependencies [e120a5a]
|
|
1405
|
+
- Updated dependencies [e5bd2f6]
|
|
1406
|
+
- Updated dependencies [e650d67]
|
|
1407
|
+
- Updated dependencies [04476e7]
|
|
1408
|
+
- Updated dependencies [67bf2e2]
|
|
1409
|
+
- Updated dependencies [eaaf03c]
|
|
1410
|
+
- Updated dependencies [d17df80]
|
|
1411
|
+
- Updated dependencies [7d0e7b5]
|
|
1412
|
+
- Updated dependencies [c6d1cb4]
|
|
1413
|
+
- Updated dependencies [6513c17]
|
|
1414
|
+
- Updated dependencies [36030ff]
|
|
1415
|
+
- Updated dependencies [79228cd]
|
|
1416
|
+
- Updated dependencies [6117f7b]
|
|
1417
|
+
- Updated dependencies [e533b0b]
|
|
1418
|
+
- Updated dependencies [cdf4d9a]
|
|
1419
|
+
- Updated dependencies [aee1806]
|
|
1420
|
+
- Updated dependencies [c13350b]
|
|
1421
|
+
- Updated dependencies [c13350b]
|
|
1422
|
+
- Updated dependencies [2c1988c]
|
|
1423
|
+
- Updated dependencies [9ca2d85]
|
|
1424
|
+
- Updated dependencies [c13350b]
|
|
1425
|
+
- Updated dependencies [891d345]
|
|
1426
|
+
- Updated dependencies [c8124e5]
|
|
1427
|
+
- Updated dependencies [a52e2ef]
|
|
1428
|
+
- Updated dependencies [5293114]
|
|
1429
|
+
- Updated dependencies [376a061]
|
|
1430
|
+
- Updated dependencies [c142ced]
|
|
1431
|
+
- Updated dependencies [211abdb]
|
|
1432
|
+
- Updated dependencies [b3363e9]
|
|
1433
|
+
- Updated dependencies [eda599e]
|
|
1434
|
+
- Updated dependencies [a1a4140]
|
|
1435
|
+
- Updated dependencies [7c7e246]
|
|
1436
|
+
- Updated dependencies [2ef1807]
|
|
1437
|
+
- Updated dependencies [f35cdc5]
|
|
1438
|
+
- Updated dependencies [d03fe25]
|
|
1439
|
+
- Updated dependencies [217e2e6]
|
|
1440
|
+
- Updated dependencies [2672f85]
|
|
1441
|
+
- Updated dependencies [20bc357]
|
|
1442
|
+
- Updated dependencies [11066f6]
|
|
1443
|
+
- Updated dependencies [916af17]
|
|
1444
|
+
- Updated dependencies [84c86fb]
|
|
1445
|
+
- Updated dependencies [2a2a9fb]
|
|
1446
|
+
- Updated dependencies [86a71d1]
|
|
1447
|
+
- Updated dependencies [c001422]
|
|
1448
|
+
- Updated dependencies [77022a9]
|
|
1449
|
+
- Updated dependencies [d5c75e2]
|
|
1450
|
+
- Updated dependencies [03d26f7]
|
|
1451
|
+
- Updated dependencies [5966c2a]
|
|
1452
|
+
- Updated dependencies [2382580]
|
|
1453
|
+
- Updated dependencies [9ea2bc5]
|
|
1454
|
+
- Updated dependencies [a2e157c]
|
|
1455
|
+
- Updated dependencies [95c4227]
|
|
1456
|
+
- Updated dependencies [2a61116]
|
|
1457
|
+
- Updated dependencies [52760bf]
|
|
1458
|
+
- Updated dependencies [5543020]
|
|
1459
|
+
- Updated dependencies [880d343]
|
|
1460
|
+
- Updated dependencies [6e82972]
|
|
1461
|
+
- Updated dependencies [d4df105]
|
|
1462
|
+
- Updated dependencies [4615a18]
|
|
1463
|
+
- Updated dependencies [f505689]
|
|
1464
|
+
- Updated dependencies [d9fa683]
|
|
1465
|
+
- Updated dependencies [606d577]
|
|
1466
|
+
- Updated dependencies [4384921]
|
|
1467
|
+
- Updated dependencies [e2798fa]
|
|
1468
|
+
- Updated dependencies [3c628ce]
|
|
1469
|
+
- Updated dependencies [c2d9098]
|
|
1470
|
+
- Updated dependencies [0fd8556]
|
|
1471
|
+
- Updated dependencies [3c7bcc0]
|
|
1472
|
+
- Updated dependencies [4b6cac7]
|
|
1473
|
+
- Updated dependencies [7631964]
|
|
1474
|
+
- Updated dependencies [ac471a0]
|
|
1475
|
+
- Updated dependencies [60ae58e]
|
|
1476
|
+
- Updated dependencies [7f62706]
|
|
1477
|
+
- Updated dependencies [667fa44]
|
|
1478
|
+
- Updated dependencies [37e38d1]
|
|
1479
|
+
- Updated dependencies [e906126]
|
|
1480
|
+
- Updated dependencies [ce92674]
|
|
1481
|
+
- Updated dependencies [08363a0]
|
|
1482
|
+
- Updated dependencies [444de5b]
|
|
1483
|
+
- Updated dependencies [a227ed7]
|
|
1484
|
+
- Updated dependencies [7cb922e]
|
|
1485
|
+
- Updated dependencies [1d22114]
|
|
1486
|
+
- Updated dependencies [1eb13a0]
|
|
1487
|
+
- Updated dependencies [c52e608]
|
|
1488
|
+
- Updated dependencies [9613396]
|
|
1489
|
+
- Updated dependencies [3f7b4ff]
|
|
1490
|
+
- Updated dependencies [74155c7]
|
|
1491
|
+
- Updated dependencies [b5f9397]
|
|
1492
|
+
- Updated dependencies [ed77493]
|
|
1493
|
+
- Updated dependencies [6908830]
|
|
1494
|
+
- Updated dependencies [8b06bba]
|
|
1495
|
+
- Updated dependencies [58a03d2]
|
|
1496
|
+
- Updated dependencies [2bacd1a]
|
|
1497
|
+
- Updated dependencies [e47b342]
|
|
1498
|
+
- Updated dependencies [4c54037]
|
|
1499
|
+
- Updated dependencies [dc530b4]
|
|
1500
|
+
- Updated dependencies [9f601e8]
|
|
1501
|
+
- Updated dependencies [6a9dec6]
|
|
1502
|
+
- Updated dependencies [0f7157b]
|
|
1503
|
+
- Updated dependencies [4dc1c7d]
|
|
1504
|
+
- Updated dependencies [d9bef45]
|
|
1505
|
+
- Updated dependencies [4dfd002]
|
|
1506
|
+
- Updated dependencies [f549a0d]
|
|
1507
|
+
- Updated dependencies [51c5227]
|
|
1508
|
+
- Updated dependencies [82da264]
|
|
1509
|
+
- Updated dependencies [77be690]
|
|
1510
|
+
- Updated dependencies [4ed7ed4]
|
|
1511
|
+
- Updated dependencies [9b9b70f]
|
|
1512
|
+
- Updated dependencies [f5a9bc2]
|
|
1513
|
+
- Updated dependencies [e59786e]
|
|
1514
|
+
- Updated dependencies [2fa4ca1]
|
|
1515
|
+
- Updated dependencies [bcf1112]
|
|
1516
|
+
- Updated dependencies [baeb4f0]
|
|
1517
|
+
- Updated dependencies [29488cc]
|
|
1518
|
+
- Updated dependencies [881a3cc]
|
|
1519
|
+
- Updated dependencies [f5a2320]
|
|
1520
|
+
- Updated dependencies [ad6317b]
|
|
1521
|
+
- Updated dependencies [811c30c]
|
|
1522
|
+
- Updated dependencies [a4a85c8]
|
|
1523
|
+
- Updated dependencies [859cb83]
|
|
1524
|
+
- Updated dependencies [07a4e26]
|
|
1525
|
+
- Updated dependencies [9774b78]
|
|
1526
|
+
- Updated dependencies [8a88885]
|
|
1527
|
+
- Updated dependencies [deb538f]
|
|
1528
|
+
- Updated dependencies [b49ccfd]
|
|
1529
|
+
- Updated dependencies [5b89711]
|
|
1530
|
+
- Updated dependencies [85d95e7]
|
|
1531
|
+
- Updated dependencies [08cd163]
|
|
1532
|
+
- Updated dependencies [0c8a22f]
|
|
1533
|
+
- Updated dependencies [5f7669e]
|
|
1534
|
+
- Updated dependencies [becbe53]
|
|
1535
|
+
- Updated dependencies [b127c8b]
|
|
1536
|
+
- Updated dependencies [763931e]
|
|
1537
|
+
- Updated dependencies [ec975f1]
|
|
1538
|
+
- Updated dependencies [168f60f]
|
|
1539
|
+
- Updated dependencies [b07d829]
|
|
1540
|
+
- Updated dependencies [de9af8a]
|
|
1541
|
+
- Updated dependencies [eb4204b]
|
|
1542
|
+
- Updated dependencies [a80302a]
|
|
1543
|
+
- Updated dependencies [a648e96]
|
|
1544
|
+
- Updated dependencies [a47ac06]
|
|
1545
|
+
- Updated dependencies [e4c61a7]
|
|
1546
|
+
- Updated dependencies [cc60165]
|
|
1547
|
+
- Updated dependencies [474f131]
|
|
1548
|
+
- Updated dependencies [081aa6f]
|
|
1549
|
+
- Updated dependencies [91f4c78]
|
|
1550
|
+
- Updated dependencies [050cd82]
|
|
1551
|
+
- Updated dependencies [4d552af]
|
|
1552
|
+
- Updated dependencies [44d677c]
|
|
1553
|
+
- Updated dependencies [c32944d]
|
|
1554
|
+
- Updated dependencies [1dd780f]
|
|
1555
|
+
- Updated dependencies [e8d0c21]
|
|
1556
|
+
- Updated dependencies [244ca86]
|
|
1557
|
+
- Updated dependencies [546ab3c]
|
|
1558
|
+
- Updated dependencies [c4df271]
|
|
1559
|
+
- Updated dependencies [c8d6f6e]
|
|
1560
|
+
- Updated dependencies [0b51bb6]
|
|
1561
|
+
- Updated dependencies [d9971d3]
|
|
1562
|
+
- Updated dependencies [7dc1067]
|
|
1563
|
+
- Updated dependencies [4f13be2]
|
|
1564
|
+
- Updated dependencies [a41ba5c]
|
|
1565
|
+
- Updated dependencies [189854c]
|
|
1566
|
+
- Updated dependencies [0e3a226]
|
|
1567
|
+
- Updated dependencies [92a67f2]
|
|
1568
|
+
- Updated dependencies [9136327]
|
|
1569
|
+
- Updated dependencies [bf0ae99]
|
|
1570
|
+
- Updated dependencies [abeb375]
|
|
1571
|
+
- Updated dependencies [cb3b6cd]
|
|
1572
|
+
- Updated dependencies [73b7234]
|
|
1573
|
+
- Updated dependencies [d2b97c3]
|
|
1574
|
+
- Updated dependencies [61cc079]
|
|
1575
|
+
- Updated dependencies [0e96e46]
|
|
1576
|
+
- Updated dependencies [c1d44f7]
|
|
1577
|
+
- Updated dependencies [59b794f]
|
|
1578
|
+
- Updated dependencies [ef4efa8]
|
|
1579
|
+
- Updated dependencies [cbb6a5c]
|
|
1580
|
+
- Updated dependencies [fc3a36a]
|
|
1581
|
+
- Updated dependencies [ab9fb5c]
|
|
1582
|
+
- Updated dependencies [69787f0]
|
|
1583
|
+
- Updated dependencies [5d022a1]
|
|
1584
|
+
- Updated dependencies [042b9ee]
|
|
1585
|
+
- Updated dependencies [f985b3f]
|
|
1586
|
+
- Updated dependencies [795b6e1]
|
|
1587
|
+
- Updated dependencies [d52d4fe]
|
|
1588
|
+
- Updated dependencies [742cebb]
|
|
1589
|
+
- Updated dependencies [175d789]
|
|
1590
|
+
- Updated dependencies [f549a0d]
|
|
1591
|
+
- Updated dependencies [427344c]
|
|
1592
|
+
- Updated dependencies [8af76ae]
|
|
1593
|
+
- Updated dependencies [1d4756e]
|
|
1594
|
+
- Updated dependencies [720c5ad]
|
|
1595
|
+
- Updated dependencies [a8d1e24]
|
|
1596
|
+
- Updated dependencies [b85cc54]
|
|
1597
|
+
- Updated dependencies [a36db28]
|
|
1598
|
+
- Updated dependencies [7a8476f]
|
|
1599
|
+
- Updated dependencies [518ca7a]
|
|
1600
|
+
- Updated dependencies [41642b0]
|
|
1601
|
+
- Updated dependencies [4cca74c]
|
|
1602
|
+
- Updated dependencies [88ef03e]
|
|
1603
|
+
- Updated dependencies [9a4932a]
|
|
1604
|
+
- Updated dependencies [3f8817a]
|
|
1605
|
+
- Updated dependencies [a2443e3]
|
|
1606
|
+
- Updated dependencies [e1554b1]
|
|
1607
|
+
- Updated dependencies [9e2caf3]
|
|
1608
|
+
- Updated dependencies [4856789]
|
|
1609
|
+
- Updated dependencies [81ce41a]
|
|
1610
|
+
- Updated dependencies [85e1e4e]
|
|
1611
|
+
- Updated dependencies [c3f4916]
|
|
1612
|
+
- Updated dependencies [55dbbba]
|
|
1613
|
+
- Updated dependencies [33e0385]
|
|
1614
|
+
- Updated dependencies [dac6a08]
|
|
1615
|
+
- Updated dependencies [72c3c86]
|
|
1616
|
+
- Updated dependencies [2d8dba3]
|
|
1617
|
+
- Updated dependencies [7f1a635]
|
|
1618
|
+
- Updated dependencies [2205363]
|
|
1619
|
+
- Updated dependencies [09fe58d]
|
|
1620
|
+
- Updated dependencies [f9fc874]
|
|
1621
|
+
- Updated dependencies [d62f8eb]
|
|
1622
|
+
- Updated dependencies [d0a5ceb]
|
|
1623
|
+
- Updated dependencies [a7586cd]
|
|
1624
|
+
- Updated dependencies [4c5e80e]
|
|
1625
|
+
- Updated dependencies [4b5702a]
|
|
1626
|
+
- Updated dependencies [011b386]
|
|
1627
|
+
- Updated dependencies [e18a162]
|
|
1628
|
+
- Updated dependencies [394b7a1]
|
|
1629
|
+
- Updated dependencies [ce92674]
|
|
1630
|
+
- Updated dependencies [cf2c9b7]
|
|
1631
|
+
- Updated dependencies [d127ff0]
|
|
1632
|
+
- Updated dependencies [36d90fc]
|
|
1633
|
+
- Updated dependencies [7777e8f]
|
|
1634
|
+
- Updated dependencies [9b86cf6]
|
|
1635
|
+
- Updated dependencies [d063a96]
|
|
1636
|
+
- Updated dependencies [8825a06]
|
|
1637
|
+
- Updated dependencies [5087ac6]
|
|
1638
|
+
- Updated dependencies [677b591]
|
|
1639
|
+
- Updated dependencies [cf7c694]
|
|
1640
|
+
- Updated dependencies [ddd0f06]
|
|
1641
|
+
- Updated dependencies [d77d1b7]
|
|
1642
|
+
- Updated dependencies [0f9faa2]
|
|
1643
|
+
- Updated dependencies [2d1ddf0]
|
|
1644
|
+
- Updated dependencies [354b00f]
|
|
1645
|
+
- Updated dependencies [3de535b]
|
|
1646
|
+
- Updated dependencies [fe2e15a]
|
|
1647
|
+
- Updated dependencies [5b79a34]
|
|
1648
|
+
- Updated dependencies [502564d]
|
|
1649
|
+
- Updated dependencies [603cab8]
|
|
1650
|
+
- Updated dependencies [c757854]
|
|
1651
|
+
- Updated dependencies [471839d]
|
|
1652
|
+
- Updated dependencies [507b92a]
|
|
1653
|
+
- Updated dependencies [b508244]
|
|
1654
|
+
- Updated dependencies [df95346]
|
|
1655
|
+
- Updated dependencies [3dede58]
|
|
1656
|
+
- Updated dependencies [c6b6bb4]
|
|
1657
|
+
- Updated dependencies [594508e]
|
|
1658
|
+
- Updated dependencies [7cf42fe]
|
|
1659
|
+
- Updated dependencies [5966c2a]
|
|
1660
|
+
- Updated dependencies [0045682]
|
|
1661
|
+
- Updated dependencies [7309c81]
|
|
1662
|
+
- Updated dependencies [2f59da0]
|
|
1663
|
+
- Updated dependencies [d56012f]
|
|
1664
|
+
- Updated dependencies [f78dd83]
|
|
1665
|
+
- Updated dependencies [a2cd18a]
|
|
1666
|
+
- Updated dependencies [9051802]
|
|
1667
|
+
- Updated dependencies [20bc1ec]
|
|
1668
|
+
- Updated dependencies [1c625ca]
|
|
1669
|
+
- Updated dependencies [2f8328c]
|
|
1670
|
+
- Updated dependencies [2a6c279]
|
|
1671
|
+
- Updated dependencies [8c8f0df]
|
|
1672
|
+
- Updated dependencies [8ad609c]
|
|
1673
|
+
- Updated dependencies [bbee302]
|
|
1674
|
+
- Updated dependencies [90c2b15]
|
|
1675
|
+
- Updated dependencies [4638aaa]
|
|
1676
|
+
- Updated dependencies [0222d3c]
|
|
1677
|
+
- Updated dependencies [08863dd]
|
|
1678
|
+
- Updated dependencies [f293d45]
|
|
1679
|
+
- Updated dependencies [56664f5]
|
|
1680
|
+
- Updated dependencies [71f205d]
|
|
1681
|
+
- Updated dependencies [f067930]
|
|
1682
|
+
- Updated dependencies [414395b]
|
|
1683
|
+
- Updated dependencies [42eeb7d]
|
|
1684
|
+
- Updated dependencies [31cbe90]
|
|
1685
|
+
- Updated dependencies [6b7129a]
|
|
1686
|
+
- Updated dependencies [97ace2a]
|
|
1687
|
+
- Updated dependencies [26e1029]
|
|
1688
|
+
- Updated dependencies [0a936ea]
|
|
1689
|
+
- Updated dependencies [90bbf25]
|
|
1690
|
+
- Updated dependencies [023c00b]
|
|
1691
|
+
- Updated dependencies [eb91eba]
|
|
1692
|
+
- Updated dependencies [42da73d]
|
|
1693
|
+
- Updated dependencies [01e124d]
|
|
1694
|
+
- Updated dependencies [ef7b5ef]
|
|
1695
|
+
- Updated dependencies [9514767]
|
|
1696
|
+
- Updated dependencies [8f20201]
|
|
1697
|
+
- Updated dependencies [155507e]
|
|
1698
|
+
- Updated dependencies [643b7c7]
|
|
1699
|
+
- Updated dependencies [7bba90b]
|
|
1700
|
+
- Updated dependencies [8813b90]
|
|
1701
|
+
- Updated dependencies [108ba8d]
|
|
1702
|
+
- Updated dependencies [2a5f04a]
|
|
1703
|
+
- Updated dependencies [4f740b0]
|
|
1704
|
+
- Updated dependencies [7ce02eb]
|
|
1705
|
+
- Updated dependencies [b4ad984]
|
|
1706
|
+
- Updated dependencies [a9f32df]
|
|
1707
|
+
- Updated dependencies [aeb9b27]
|
|
1708
|
+
- Updated dependencies [7d27da0]
|
|
1709
|
+
- Updated dependencies [1a15893]
|
|
1710
|
+
- Updated dependencies [b70e534]
|
|
1711
|
+
- Updated dependencies [7e05d8e]
|
|
1712
|
+
- Updated dependencies [8f1851e]
|
|
1713
|
+
- Updated dependencies [61ea810]
|
|
1714
|
+
- Updated dependencies [2233a85]
|
|
1715
|
+
- Updated dependencies [67452d1]
|
|
1716
|
+
- Updated dependencies [089767f]
|
|
1717
|
+
- Updated dependencies [a13827e]
|
|
1718
|
+
- Updated dependencies [66d99ec]
|
|
1719
|
+
- Updated dependencies [cb43296]
|
|
1720
|
+
- Updated dependencies [b61afc1]
|
|
1721
|
+
- Updated dependencies [79021fc]
|
|
1722
|
+
- Updated dependencies [7733604]
|
|
1723
|
+
- Updated dependencies [40e420f]
|
|
1724
|
+
- Updated dependencies [62dd69a]
|
|
1725
|
+
- Updated dependencies [d13004a]
|
|
1726
|
+
- Updated dependencies [e15e679]
|
|
1727
|
+
- Updated dependencies [2ab1257]
|
|
1728
|
+
- Updated dependencies [0fc6219]
|
|
1729
|
+
- Updated dependencies [061406d]
|
|
1730
|
+
- Updated dependencies [e4c8b6c]
|
|
1731
|
+
- Updated dependencies [acb10f6]
|
|
1732
|
+
- Updated dependencies [605e190]
|
|
1733
|
+
- Updated dependencies [c6c59f1]
|
|
1734
|
+
- Updated dependencies [b0e78a8]
|
|
1735
|
+
- Updated dependencies [f31cc8d]
|
|
1736
|
+
- Updated dependencies [f343dc4]
|
|
1737
|
+
- Updated dependencies [8269e32]
|
|
1738
|
+
- Updated dependencies [74f7339]
|
|
1739
|
+
- Updated dependencies [a6c35a2]
|
|
1740
|
+
- Updated dependencies [c2f1002]
|
|
1741
|
+
- Updated dependencies [4cc4fb7]
|
|
1742
|
+
- Updated dependencies [97b6658]
|
|
1743
|
+
- Updated dependencies [2c26040]
|
|
1744
|
+
- Updated dependencies [f758cec]
|
|
1745
|
+
- Updated dependencies [5b47ab5]
|
|
1746
|
+
- Updated dependencies [b09d8d9]
|
|
1747
|
+
- Updated dependencies [b09d8d9]
|
|
1748
|
+
- Updated dependencies [8675db6]
|
|
1749
|
+
- Updated dependencies [b09d8d9]
|
|
1750
|
+
- Updated dependencies [27358d5]
|
|
1751
|
+
- Updated dependencies [1c3da1f]
|
|
1752
|
+
- Updated dependencies [c1f344b]
|
|
1753
|
+
- Updated dependencies [3eb1b2b]
|
|
1754
|
+
- Updated dependencies [9c93465]
|
|
1755
|
+
- Updated dependencies [a34fd2e]
|
|
1756
|
+
- Updated dependencies [ebb209c]
|
|
1757
|
+
- Updated dependencies [76bcb83]
|
|
1758
|
+
- Updated dependencies [59b85c0]
|
|
1759
|
+
- Updated dependencies [889ae47]
|
|
1760
|
+
- Updated dependencies [4f4c3fb]
|
|
1761
|
+
- Updated dependencies [78f0be8]
|
|
1762
|
+
- Updated dependencies [6e357ed]
|
|
1763
|
+
- Updated dependencies [d6938bf]
|
|
1764
|
+
- Updated dependencies [35f7fb4]
|
|
1765
|
+
- Updated dependencies [0410522]
|
|
1766
|
+
- Updated dependencies [63b33e6]
|
|
1767
|
+
- Updated dependencies [f163028]
|
|
1768
|
+
- Updated dependencies [814db6d]
|
|
1769
|
+
- Updated dependencies [a5302c7]
|
|
1770
|
+
- Updated dependencies [31e0be9]
|
|
1771
|
+
- Updated dependencies [4bfd455]
|
|
1772
|
+
- Updated dependencies [ffd2ce2]
|
|
1773
|
+
- Updated dependencies [2a44c1d]
|
|
1774
|
+
- Updated dependencies [7084313]
|
|
1775
|
+
- Updated dependencies [f07808c]
|
|
1776
|
+
- Updated dependencies [7ffc3d3]
|
|
1777
|
+
- Updated dependencies [88346ba]
|
|
1778
|
+
- Updated dependencies [4631592]
|
|
1779
|
+
- Updated dependencies [62f8017]
|
|
1780
|
+
- Updated dependencies [32ff033]
|
|
1781
|
+
- Updated dependencies [a831df1]
|
|
1782
|
+
- Updated dependencies [f752ee3]
|
|
1783
|
+
- Updated dependencies [a1b61e0]
|
|
1784
|
+
- Updated dependencies [cd6b9f2]
|
|
1785
|
+
- Updated dependencies [2cb6d3c]
|
|
1786
|
+
- Updated dependencies [af2a095]
|
|
1787
|
+
- Updated dependencies [5ac93d4]
|
|
1788
|
+
- Updated dependencies [695cfbd]
|
|
1789
|
+
- Updated dependencies [0e043d8]
|
|
1790
|
+
- Updated dependencies [93f267f]
|
|
1791
|
+
- Updated dependencies [7445149]
|
|
1792
|
+
- Updated dependencies [ec796d5]
|
|
1793
|
+
- Updated dependencies [071d0dc]
|
|
1794
|
+
- Updated dependencies [0024abf]
|
|
1795
|
+
- Updated dependencies [8dd98bf]
|
|
1796
|
+
- Updated dependencies [e87fea1]
|
|
1797
|
+
- Updated dependencies [c65e529]
|
|
1798
|
+
- Updated dependencies [0848bea]
|
|
1799
|
+
- Updated dependencies [d51bed2]
|
|
1800
|
+
- Updated dependencies [dadd1ad]
|
|
1801
|
+
- Updated dependencies [acbf364]
|
|
1802
|
+
- Updated dependencies [3ca34c1]
|
|
1803
|
+
- Updated dependencies [7adc841]
|
|
1804
|
+
- Updated dependencies [239c3a3]
|
|
1805
|
+
- Updated dependencies [b8b3c64]
|
|
1806
|
+
- Updated dependencies [2f2e63c]
|
|
1807
|
+
- Updated dependencies [4845f85]
|
|
1808
|
+
- Updated dependencies [486d526]
|
|
1809
|
+
- Updated dependencies [94a0bbc]
|
|
1810
|
+
- Updated dependencies [d6bfb3d]
|
|
1811
|
+
- Updated dependencies [8a9c079]
|
|
1812
|
+
- Updated dependencies [7b005b4]
|
|
1813
|
+
- Updated dependencies [cc3555e]
|
|
1814
|
+
- Updated dependencies [a2266a6]
|
|
1815
|
+
- Updated dependencies [d25a0ec]
|
|
1816
|
+
- Updated dependencies [89d7b35]
|
|
1817
|
+
- Updated dependencies [94f7b6a]
|
|
1818
|
+
- Updated dependencies [5c94f83]
|
|
1819
|
+
- Updated dependencies [ea936f3]
|
|
1820
|
+
- Updated dependencies [0c0fbd9]
|
|
1821
|
+
- Updated dependencies [667b83e]
|
|
1822
|
+
- Updated dependencies [f3141d8]
|
|
1823
|
+
- Updated dependencies [7687f7b]
|
|
1824
|
+
- Updated dependencies [5a84d41]
|
|
1825
|
+
- Updated dependencies [fd3013a]
|
|
1826
|
+
- Updated dependencies [85ec26d]
|
|
1827
|
+
- Updated dependencies [73e576f]
|
|
1828
|
+
- Updated dependencies [f6476fc]
|
|
1829
|
+
- Updated dependencies [69ac82c]
|
|
1830
|
+
- Updated dependencies [4ac12ef]
|
|
1831
|
+
- Updated dependencies [833ed84]
|
|
1832
|
+
- Updated dependencies [a18abf3]
|
|
1833
|
+
- Updated dependencies [c6a4eeb]
|
|
1834
|
+
- Updated dependencies [1659072]
|
|
1835
|
+
- Updated dependencies [f450ae7]
|
|
1836
|
+
- Updated dependencies [abceb0d]
|
|
1837
|
+
- Updated dependencies [627b188]
|
|
1838
|
+
- Updated dependencies [8d4eae7]
|
|
1839
|
+
- Updated dependencies [c5a5996]
|
|
1840
|
+
- Updated dependencies [0c302a7]
|
|
1841
|
+
- Updated dependencies [b88f5e8]
|
|
1842
|
+
- Updated dependencies [65a3a84]
|
|
1843
|
+
- Updated dependencies [6633337]
|
|
1844
|
+
- Updated dependencies [21676eb]
|
|
1845
|
+
- Updated dependencies [e9cb9ab]
|
|
1846
|
+
- Updated dependencies [42cc219]
|
|
1847
|
+
- Updated dependencies [d7e0b42]
|
|
1848
|
+
- Updated dependencies [3510e4a]
|
|
1849
|
+
- Updated dependencies [f00d8d4]
|
|
1850
|
+
- Updated dependencies [5326b36]
|
|
1851
|
+
- Updated dependencies [aa4b90d]
|
|
1852
|
+
- Updated dependencies [ccd9397]
|
|
1853
|
+
- Updated dependencies [503be86]
|
|
1854
|
+
- Updated dependencies [54299ca]
|
|
1855
|
+
- Updated dependencies [ae490ef]
|
|
1856
|
+
- Updated dependencies [e124711]
|
|
1857
|
+
- Updated dependencies [dc61def]
|
|
1858
|
+
- Updated dependencies [bca935b]
|
|
1859
|
+
- Updated dependencies [c54c822]
|
|
1860
|
+
- Updated dependencies [8dcc0f5]
|
|
1861
|
+
- Updated dependencies [75b9e51]
|
|
1862
|
+
- Updated dependencies [f61c8cf]
|
|
1863
|
+
- Updated dependencies [e3ef52b]
|
|
1864
|
+
- Updated dependencies [0a2f233]
|
|
1865
|
+
- Updated dependencies [8621cdd]
|
|
1866
|
+
- Updated dependencies [251e888]
|
|
1867
|
+
- Updated dependencies [07f1822]
|
|
1868
|
+
- Updated dependencies [e336549]
|
|
1869
|
+
- Updated dependencies [3bb9340]
|
|
1870
|
+
- Updated dependencies [1e604c4]
|
|
1871
|
+
- Updated dependencies [04fab5e]
|
|
1872
|
+
- Updated dependencies [183b4c4]
|
|
1873
|
+
- Updated dependencies [7f713b6]
|
|
1874
|
+
- Updated dependencies [d40f43a]
|
|
1875
|
+
- Updated dependencies [2fdb36e]
|
|
1876
|
+
- Updated dependencies [6f23667]
|
|
1877
|
+
- Updated dependencies [cde1975]
|
|
1878
|
+
- Updated dependencies [0bc685a]
|
|
1879
|
+
- Updated dependencies [20526f5]
|
|
1880
|
+
- Updated dependencies [efedd28]
|
|
1881
|
+
- Updated dependencies [5d21a48]
|
|
1882
|
+
- Updated dependencies [5278e11]
|
|
1883
|
+
- Updated dependencies [c5eef1d]
|
|
1884
|
+
- Updated dependencies [e5e7ee0]
|
|
1885
|
+
- Updated dependencies [23dba62]
|
|
1886
|
+
- Updated dependencies [e0f300b]
|
|
1887
|
+
- Updated dependencies [761a0ba]
|
|
1888
|
+
- Updated dependencies [c960170]
|
|
1889
|
+
- Updated dependencies [19365b7]
|
|
1890
|
+
- Updated dependencies [ba98e26]
|
|
1891
|
+
- Updated dependencies [b7ed26d]
|
|
1892
|
+
- Updated dependencies [a2ebea2]
|
|
1893
|
+
- Updated dependencies [800bdb0]
|
|
1894
|
+
- Updated dependencies [9d4dfc4]
|
|
1895
|
+
- Updated dependencies [1059965]
|
|
1896
|
+
- Updated dependencies [def5919]
|
|
1897
|
+
- Updated dependencies [60b672e]
|
|
1898
|
+
- Updated dependencies [6b441a8]
|
|
1899
|
+
- Updated dependencies [ce0cfe9]
|
|
1900
|
+
- Updated dependencies [04f1182]
|
|
1901
|
+
- Updated dependencies [be87153]
|
|
1902
|
+
- Updated dependencies [dd0f681]
|
|
1903
|
+
- Updated dependencies [60f0dd8]
|
|
1904
|
+
- Updated dependencies [a87c5cd]
|
|
1905
|
+
- Updated dependencies [a47f338]
|
|
1906
|
+
- Updated dependencies [b3a3d83]
|
|
1907
|
+
- Updated dependencies [7a55913]
|
|
1908
|
+
- Updated dependencies [35accbf]
|
|
1909
|
+
- Updated dependencies [6038de7]
|
|
1910
|
+
- Updated dependencies [fc5f536]
|
|
1911
|
+
- Updated dependencies [5647006]
|
|
1912
|
+
- Updated dependencies [e654bfd]
|
|
1913
|
+
- Updated dependencies [01a7337]
|
|
1914
|
+
- Updated dependencies [b45c71e]
|
|
1915
|
+
- Updated dependencies [f8cfbb4]
|
|
1916
|
+
- Updated dependencies [6e6c872]
|
|
1917
|
+
- Updated dependencies [2598216]
|
|
1918
|
+
- Updated dependencies [11949fc]
|
|
1919
|
+
- Updated dependencies [2c7e62d]
|
|
1920
|
+
- Updated dependencies [eb95d97]
|
|
1921
|
+
- Updated dependencies [b098b0e]
|
|
1922
|
+
- Updated dependencies [4d00b13]
|
|
1923
|
+
- Updated dependencies [1363084]
|
|
1924
|
+
- Updated dependencies [fa5758e]
|
|
1925
|
+
- Updated dependencies [38f7e4f]
|
|
1926
|
+
- Updated dependencies [eb7613c]
|
|
1927
|
+
- Updated dependencies [c57f3cf]
|
|
1928
|
+
- Updated dependencies [ecc9110]
|
|
1929
|
+
- Updated dependencies [e4c2dc8]
|
|
1930
|
+
- Updated dependencies [97faca3]
|
|
1931
|
+
- Updated dependencies [57bab76]
|
|
1932
|
+
- Updated dependencies [c89d18c]
|
|
1933
|
+
- Updated dependencies [1bd2795]
|
|
1934
|
+
- Updated dependencies [f7bd4e2]
|
|
1935
|
+
- Updated dependencies [361bd5b]
|
|
1936
|
+
- Updated dependencies [aac90a5]
|
|
1937
|
+
- Updated dependencies [3da3da5]
|
|
1938
|
+
- Updated dependencies [1e6ab15]
|
|
1939
|
+
- Updated dependencies [b90086a]
|
|
1940
|
+
- Updated dependencies [8186a70]
|
|
1941
|
+
- Updated dependencies [a329cca]
|
|
1942
|
+
- Updated dependencies [c87ef70]
|
|
1943
|
+
- Updated dependencies [3cb0618]
|
|
1944
|
+
- Updated dependencies [32a0874]
|
|
1945
|
+
- Updated dependencies [6eec18c]
|
|
1946
|
+
- Updated dependencies [4d7bebf]
|
|
1947
|
+
- Updated dependencies [821ac7a]
|
|
1948
|
+
- Updated dependencies [8f81731]
|
|
1949
|
+
- Updated dependencies [7055c22]
|
|
1950
|
+
- Updated dependencies [785a748]
|
|
1951
|
+
- Updated dependencies [3af0354]
|
|
1952
|
+
- Updated dependencies [866ff16]
|
|
1953
|
+
- Updated dependencies [5a85e67]
|
|
1954
|
+
- Updated dependencies [8b50cb3]
|
|
1955
|
+
- Updated dependencies [a0fdc56]
|
|
1956
|
+
- Updated dependencies [b95577a]
|
|
1957
|
+
- Updated dependencies [0dcbc11]
|
|
1958
|
+
- Updated dependencies [d88f3e9]
|
|
1959
|
+
- Updated dependencies [ad5fe25]
|
|
1960
|
+
- Updated dependencies [c183a12]
|
|
1961
|
+
- Updated dependencies [83c161f]
|
|
1962
|
+
- Updated dependencies [d8c4957]
|
|
1963
|
+
- Updated dependencies [b9f930b]
|
|
1964
|
+
- Updated dependencies [f24cb83]
|
|
1965
|
+
- Updated dependencies [5dbbb92]
|
|
1966
|
+
- Updated dependencies [ea90179]
|
|
1967
|
+
- Updated dependencies [1818998]
|
|
1968
|
+
- Updated dependencies [ce92674]
|
|
1969
|
+
- Updated dependencies [5ef0b5b]
|
|
1970
|
+
- Updated dependencies [8c2db68]
|
|
1971
|
+
- Updated dependencies [22b5e54]
|
|
1972
|
+
- Updated dependencies [0166bd5]
|
|
1973
|
+
- Updated dependencies [8064b07]
|
|
1974
|
+
- Updated dependencies [09ee21c]
|
|
1975
|
+
- Updated dependencies [4a56dbd]
|
|
1976
|
+
- Updated dependencies [289d04a]
|
|
1977
|
+
- Updated dependencies [f549a0d]
|
|
1978
|
+
- Updated dependencies [48fbacb]
|
|
1979
|
+
- Updated dependencies [06df4fa]
|
|
1980
|
+
- Updated dependencies [3fc2e48]
|
|
1981
|
+
- Updated dependencies [c9b809f]
|
|
1982
|
+
- Updated dependencies [e8f435c]
|
|
1983
|
+
- Updated dependencies [32386f8]
|
|
1984
|
+
- Updated dependencies [9b702dc]
|
|
1985
|
+
- Updated dependencies [ab16331]
|
|
1986
|
+
- Updated dependencies [41610f6]
|
|
1987
|
+
- Updated dependencies [69f1dfd]
|
|
1988
|
+
- Updated dependencies [bbe05de]
|
|
1989
|
+
- Updated dependencies [355e951]
|
|
1990
|
+
- Updated dependencies [a1dd1e4]
|
|
1991
|
+
- Updated dependencies [dadb43f]
|
|
1992
|
+
- @objectstack/spec@17.0.0
|
|
1993
|
+
|
|
1994
|
+
## 17.0.0-rc.6
|
|
1995
|
+
|
|
1996
|
+
### Minor Changes
|
|
1997
|
+
|
|
1998
|
+
- 91cefb8: refactor(types,rest,metadata,analytics): Postgres 的 `"x" of relation "y"` 短语收归一处，三个包不再各修一遍同一个超串洞（#6615）
|
|
1999
|
+
|
|
2000
|
+
Postgres 把「关系内部某个子对象」的失败写成 `column "label" of relation "sys_team" does not exist`——里面**逐字包含**一句合法的「表不存在」短语 `relation "sys_team" does not exist`，含义却相反：关系正因为存在才被点名。任何对「这句话是不是在说表没了」的正则收紧都消不掉这个匹配，短语确实在里面；唯一的修法是**先问更具体的问题**。所以修的是**顺序**，不是模式。
|
|
2001
|
+
|
|
2002
|
+
正因为如此，这个短语被分三次教给了这个仓库，分属三个包、三个 PR，其中两次是在别处已经踩过同一个洞之后：`@objectstack/rest` 的 `mapDataError`（#5352）、`@objectstack/service-analytics` 的缺列扣除（#6035 / PR #6346）、`@objectstack/metadata` 的 `MISSING_TABLE.excludes`（#6347 / PR #6613）。本次把它收进 `@objectstack/types`，与 `isUniqueViolationError`（#6250）和 `isModuleNotFoundError`（framework#3265）同一个理由与同一个位置。
|
|
2003
|
+
|
|
2004
|
+
**两种宽度，故意保留成两个导出。** 三个消费者要的并不是同一条正则，差别也不是随手写的，而是**每个站点哪个方向的误差是安全的**：
|
|
2005
|
+
|
|
2006
|
+
- `matchMissingColumnOfRelation(message)` —— 严格提取器，锚定 Postgres 的 errmsg 模板 `column "%s" of relation "%s" does not exist`，返回列名。`rest` 用它把 42703 答成 `400 INVALID_FIELD` 而不是 `404`；`service-analytics` 用它在分类前扣除缺列。这两处**过宽**会把真正缺失的表变成硬失败、回退 #5033 刻意保留的宽容，**漏匹配**只是让消息含糊一点——所以必须严格。
|
|
2007
|
+
- `isRelationSubObjectPhrase(message)` —— 宽检测器，丢掉 `column` / `[a-z0-9_]+` / `does not exist` 三个锚点：任意子对象、任意带引号标识符、任意判词。`metadata` 用它做排除。这一处**过宽**只会把良性判定变成响亮判定，**漏匹配**却会让 `event_seq` 从 1 重新开始、撞进一张已有行的历史表——方向正好相反。
|
|
2008
|
+
|
|
2009
|
+
把两者合并成一条正则，无论哪种宽度胜出都会对其中一个调用方是错的；这是卡片记录在案的风险，两个导出即为此而设，理由是承重的而非风格的。仓库里第四份拷贝（`service-analytics` 测试内用于守护 fixture 的那条正则）同时收编：它本是为「两张面孔别对不上」而写，却把断言打在其中一面的私有复述上，因而正是它要防的漂移。
|
|
2010
|
+
|
|
2011
|
+
行为逐字保持不变：搬进来的两条模式与原站点逐字节相同。`@objectstack/service-analytics` 因此新增一条对 `@objectstack/types` 的依赖边——这是本次唯一的依赖变化，构造上无环（`@objectstack/types` 只依赖 `@objectstack/spec`，后者无仓内依赖），且仓库 73 个包中已有 25 个、16 个 service 中已有 5 个携带同一条边。
|
|
2012
|
+
|
|
2013
|
+
- 129b378: fix(types,rest): one named answer for "which column conflicted" — an index name is never returned as one (#6544)
|
|
2014
|
+
|
|
2015
|
+
#6250 retired four private "is this a unique violation?" vocabularies into
|
|
2016
|
+
`isUniqueViolationError`. It left the harder half of the question behind: the
|
|
2017
|
+
import runner's `sanitizeRowError` still carried its own three-dialect regex
|
|
2018
|
+
chain, because it does **more** than answer yes/no — it names the offending
|
|
2019
|
+
column so the importer can say _"A record with this `email` already exists."_
|
|
2020
|
+
This lands that second answer as a shared export and migrates the last private
|
|
2021
|
+
copy onto it.
|
|
2022
|
+
|
|
2023
|
+
**New — `uniqueViolationColumn(error)` in `@objectstack/types`** (`string |
|
|
2024
|
+
undefined`), sibling to `isUniqueViolationError` and gated on it, reading the
|
|
2025
|
+
same channels one step down the same bounded `cause` chain, plus
|
|
2026
|
+
node-postgres' `detail` field.
|
|
2027
|
+
|
|
2028
|
+
**Its contract, per the maintainer's 2026-08-08 ruling: a value comes back only
|
|
2029
|
+
when the identifier the driver printed is determinably a COLUMN.** When a
|
|
2030
|
+
dialect names an _index_ instead — MySQL's `Duplicate entry … for key
|
|
2031
|
+
'idx_email_unique'`, Postgres' `violates unique constraint "sys_user_email_key"`,
|
|
2032
|
+
SQLite's `UNIQUE constraint failed: index 'x'` — the answer is `undefined`,
|
|
2033
|
+
never the index name. Callers render this into a form field, and an index name
|
|
2034
|
+
mistaken for a column points the user at a field that does not exist, whereas
|
|
2035
|
+
`undefined` degrades to generic copy. A **composite** key (`Key (tenant_id,
|
|
2036
|
+
email)=(…)`) is `undefined` for the same reason: there is no single offending
|
|
2037
|
+
column, and naming the first is the same class of wrong answer.
|
|
2038
|
+
|
|
2039
|
+
**⚠️ User-visible change on MySQL imports.** MySQL's duplicate-entry message
|
|
2040
|
+
names the index and never the column, so the importer no longer names a column
|
|
2041
|
+
there: rows that used to read _"A record with this `idx_email_unique` already
|
|
2042
|
+
exists."_ — or, on MySQL 8's table-qualified `for key 'sys_user.email'`, a
|
|
2043
|
+
plausible-looking _`email`_ that was still an index name — now read **"A record
|
|
2044
|
+
with this value already exists."** That is deliberate and is the accepted cost
|
|
2045
|
+
of the ruling. The conflict is still recognised as a conflict; only the naming
|
|
2046
|
+
narrowed.
|
|
2047
|
+
|
|
2048
|
+
Three smaller import messages improve in the same move, all previously wrong
|
|
2049
|
+
rather than merely vague:
|
|
2050
|
+
|
|
2051
|
+
- SQLite's expression/partial-index form used to render as _"A record with this
|
|
2052
|
+
**index** already exists."_
|
|
2053
|
+
- Postgres' expression index used to render the truncated fragment _"A record
|
|
2054
|
+
with this **lower(email** already exists."_
|
|
2055
|
+
- A Postgres conflict with no `DETAIL:` line used to fall through to the SQL
|
|
2056
|
+
backstop and echo the driver's own sentence — index name included — at the
|
|
2057
|
+
importer. It now gets the same generic conflict copy, which is also the exact
|
|
2058
|
+
wording `mapDataError` puts in the 409 `UNIQUE_VIOLATION` body, so the
|
|
2059
|
+
importer and the API say one thing about one condition.
|
|
2060
|
+
|
|
2061
|
+
Not changed: the NOT NULL branch, the raw-SQL backstop, and every non-conflict
|
|
2062
|
+
message, which pass through exactly as before.
|
|
2063
|
+
|
|
2064
|
+
### Patch Changes
|
|
2065
|
+
|
|
2066
|
+
- 88f9d94: fix(types,rest): one named unique-violation predicate — a MySQL conflict is 409 UNIQUE_VIOLATION, not 500 (#6250)
|
|
2067
|
+
|
|
2068
|
+
**On MySQL, every unique-constraint conflict came back as `500 INTERNAL_ERROR`.**
|
|
2069
|
+
The API contract registers `UNIQUE_VIOLATION` as a 409 code
|
|
2070
|
+
(`packages/spec/src/api/error-code-ledger.zod.ts`), so a front end had no way to
|
|
2071
|
+
tell "this email is already taken" from "the server fell over" — no retry advice,
|
|
2072
|
+
no field to point at, and a 5xx in the operator's dashboards for what is an
|
|
2073
|
+
ordinary client outcome. SQLite and Postgres deployments never saw it, which is
|
|
2074
|
+
why it survived: their conflict prose happens to contain the words the mapping
|
|
2075
|
+
looked for.
|
|
2076
|
+
|
|
2077
|
+
**Cause: the conflict verdict was nested inside a leak heuristic.** REST's 409
|
|
2078
|
+
branch lived inside the true-branch of `looksLikeInternalErrorLeak()`, keyed on
|
|
2079
|
+
the substrings `unique constraint` / `unique violation`. MySQL says
|
|
2080
|
+
`ER_DUP_ENTRY: Duplicate entry '…' for key '…'`, which matches no limb of that
|
|
2081
|
+
heuristic, so the conflict never reached the `if` at all and fell out of the
|
|
2082
|
+
terminal `UNCLASSIFIED_FAULT`. Two unrelated questions — "is this a conflict?"
|
|
2083
|
+
and "would echoing this text leak internals?" — had been fused into one, and
|
|
2084
|
+
MySQL is where they disagree.
|
|
2085
|
+
|
|
2086
|
+
Measured on the previous release, through the real error mapper:
|
|
2087
|
+
|
|
2088
|
+
```
|
|
2089
|
+
mysql, bare message 500 INTERNAL_ERROR → 409 UNIQUE_VIOLATION
|
|
2090
|
+
mysql, knex-wrapped SQL 500 DATABASE_ERROR → 409 UNIQUE_VIOLATION
|
|
2091
|
+
postgres, SQLSTATE only 500 INTERNAL_ERROR → 409 UNIQUE_VIOLATION
|
|
2092
|
+
sqlite, message 409 UNIQUE_VIOLATION (unchanged)
|
|
2093
|
+
postgres, message 409 UNIQUE_VIOLATION (unchanged)
|
|
2094
|
+
```
|
|
2095
|
+
|
|
2096
|
+
So the hole was never MySQL-only: the mapping read one of the two channels
|
|
2097
|
+
drivers use. A Postgres error carrying SQLSTATE `23505` with unremarkable prose
|
|
2098
|
+
was a 500 as well.
|
|
2099
|
+
|
|
2100
|
+
**New: `isUniqueViolationError(error)`, exported from `@objectstack/types`.** One
|
|
2101
|
+
named predicate replaces the substring test, reading every channel a driver
|
|
2102
|
+
uses — `code` (`23505` / `ER_DUP_ENTRY` / `SQLITE_CONSTRAINT_UNIQUE`), `errno`
|
|
2103
|
+
(`1062`), the message, and one step down the `cause` chain that pool and
|
|
2104
|
+
query-builder layers wrap with. Its vocabulary is the union of the four
|
|
2105
|
+
hand-written copies the repo already carried, so routing REST through it cannot
|
|
2106
|
+
narrow any verdict clients rely on today; an unrecognised error is never a
|
|
2107
|
+
conflict, because a false 409 tells an SDK not to retry and points the user at a
|
|
2108
|
+
value that is fine.
|
|
2109
|
+
|
|
2110
|
+
**The internal-leak classifier is byte-identical.** The fix hoists the conflict
|
|
2111
|
+
question out of it rather than widening its criteria, so nothing else it guards
|
|
2112
|
+
is reclassified as safe-to-expose. And the 409 body is fixed text: MySQL embeds
|
|
2113
|
+
the offending user data in its message (`Duplicate entry 'a@b.com' …`) and
|
|
2114
|
+
Postgres the index and column names, none of which reaches the client. The full
|
|
2115
|
+
driver text still reaches the server log.
|
|
2116
|
+
|
|
2117
|
+
No action needed. Clients that already handled `409 UNIQUE_VIOLATION` on SQLite
|
|
2118
|
+
and Postgres now receive it on MySQL too.
|
|
2119
|
+
|
|
2120
|
+
- Updated dependencies [3d5c090]
|
|
2121
|
+
- Updated dependencies [e5bd768]
|
|
2122
|
+
- Updated dependencies [e027b3e]
|
|
2123
|
+
- Updated dependencies [c2429b0]
|
|
2124
|
+
- Updated dependencies [445a0c2]
|
|
2125
|
+
- Updated dependencies [f6609e6]
|
|
2126
|
+
- Updated dependencies [a70358a]
|
|
2127
|
+
- Updated dependencies [97e7e3c]
|
|
2128
|
+
- Updated dependencies [8828b9e]
|
|
2129
|
+
- Updated dependencies [53068c1]
|
|
2130
|
+
- Updated dependencies [ee58392]
|
|
2131
|
+
- Updated dependencies [f16e54e]
|
|
2132
|
+
- Updated dependencies [06be54e]
|
|
2133
|
+
- Updated dependencies [259459d]
|
|
2134
|
+
- Updated dependencies [3f7f14e]
|
|
2135
|
+
- Updated dependencies [6968885]
|
|
2136
|
+
- Updated dependencies [eaed61f]
|
|
2137
|
+
- Updated dependencies [debe2f6]
|
|
2138
|
+
- Updated dependencies [97b0798]
|
|
2139
|
+
- Updated dependencies [43a7a8d]
|
|
2140
|
+
- Updated dependencies [73f69dc]
|
|
2141
|
+
- Updated dependencies [04c56aa]
|
|
2142
|
+
- Updated dependencies [b3efeb7]
|
|
2143
|
+
- Updated dependencies [ddd075a]
|
|
2144
|
+
- Updated dependencies [88154be]
|
|
2145
|
+
- Updated dependencies [e8dc61e]
|
|
2146
|
+
- Updated dependencies [2f3e793]
|
|
2147
|
+
- Updated dependencies [d8e8d9c]
|
|
2148
|
+
- Updated dependencies [94e749b]
|
|
2149
|
+
- Updated dependencies [ea1d916]
|
|
2150
|
+
- Updated dependencies [ae31a19]
|
|
2151
|
+
- Updated dependencies [e0f300b]
|
|
2152
|
+
- Updated dependencies [62b6a2f]
|
|
2153
|
+
- Updated dependencies [5b4780b]
|
|
2154
|
+
- Updated dependencies [a933452]
|
|
2155
|
+
- Updated dependencies [8140915]
|
|
2156
|
+
- Updated dependencies [7b48cf9]
|
|
2157
|
+
- Updated dependencies [b5404f4]
|
|
2158
|
+
- Updated dependencies [f764691]
|
|
2159
|
+
- Updated dependencies [e120a5a]
|
|
2160
|
+
- Updated dependencies [e650d67]
|
|
2161
|
+
- Updated dependencies [04476e7]
|
|
2162
|
+
- Updated dependencies [79228cd]
|
|
2163
|
+
- Updated dependencies [b3363e9]
|
|
2164
|
+
- Updated dependencies [2ef1807]
|
|
2165
|
+
- Updated dependencies [d03fe25]
|
|
2166
|
+
- Updated dependencies [2672f85]
|
|
2167
|
+
- Updated dependencies [11066f6]
|
|
2168
|
+
- Updated dependencies [916af17]
|
|
2169
|
+
- Updated dependencies [84c86fb]
|
|
2170
|
+
- Updated dependencies [2a2a9fb]
|
|
2171
|
+
- Updated dependencies [a2e157c]
|
|
2172
|
+
- Updated dependencies [95c4227]
|
|
2173
|
+
- Updated dependencies [2a61116]
|
|
2174
|
+
- Updated dependencies [d4df105]
|
|
2175
|
+
- Updated dependencies [e2798fa]
|
|
2176
|
+
- Updated dependencies [0fd8556]
|
|
2177
|
+
- Updated dependencies [74155c7]
|
|
2178
|
+
- Updated dependencies [6908830]
|
|
2179
|
+
- Updated dependencies [8b06bba]
|
|
2180
|
+
- Updated dependencies [4c54037]
|
|
2181
|
+
- Updated dependencies [0f7157b]
|
|
2182
|
+
- Updated dependencies [d9bef45]
|
|
2183
|
+
- Updated dependencies [f549a0d]
|
|
2184
|
+
- Updated dependencies [82da264]
|
|
2185
|
+
- Updated dependencies [9b9b70f]
|
|
2186
|
+
- Updated dependencies [f5a9bc2]
|
|
2187
|
+
- Updated dependencies [881a3cc]
|
|
2188
|
+
- Updated dependencies [ad6317b]
|
|
2189
|
+
- Updated dependencies [8a88885]
|
|
2190
|
+
- Updated dependencies [5f7669e]
|
|
2191
|
+
- Updated dependencies [becbe53]
|
|
2192
|
+
- Updated dependencies [b127c8b]
|
|
2193
|
+
- Updated dependencies [a80302a]
|
|
2194
|
+
- Updated dependencies [474f131]
|
|
2195
|
+
- Updated dependencies [050cd82]
|
|
2196
|
+
- Updated dependencies [4d552af]
|
|
2197
|
+
- Updated dependencies [44d677c]
|
|
2198
|
+
- Updated dependencies [c32944d]
|
|
2199
|
+
- Updated dependencies [1dd780f]
|
|
2200
|
+
- Updated dependencies [c8d6f6e]
|
|
2201
|
+
- Updated dependencies [92a67f2]
|
|
2202
|
+
- Updated dependencies [9136327]
|
|
2203
|
+
- Updated dependencies [bf0ae99]
|
|
2204
|
+
- Updated dependencies [cb3b6cd]
|
|
2205
|
+
- Updated dependencies [73b7234]
|
|
2206
|
+
- Updated dependencies [d2b97c3]
|
|
2207
|
+
- Updated dependencies [59b794f]
|
|
2208
|
+
- Updated dependencies [fc3a36a]
|
|
2209
|
+
- Updated dependencies [69787f0]
|
|
2210
|
+
- Updated dependencies [5d022a1]
|
|
2211
|
+
- Updated dependencies [042b9ee]
|
|
2212
|
+
- Updated dependencies [f549a0d]
|
|
2213
|
+
- Updated dependencies [a36db28]
|
|
2214
|
+
- Updated dependencies [3f8817a]
|
|
2215
|
+
- Updated dependencies [a2443e3]
|
|
2216
|
+
- Updated dependencies [e1554b1]
|
|
2217
|
+
- Updated dependencies [4856789]
|
|
2218
|
+
- Updated dependencies [c3f4916]
|
|
2219
|
+
- Updated dependencies [33e0385]
|
|
2220
|
+
- Updated dependencies [2205363]
|
|
2221
|
+
- Updated dependencies [09fe58d]
|
|
2222
|
+
- Updated dependencies [d0a5ceb]
|
|
2223
|
+
- Updated dependencies [e18a162]
|
|
2224
|
+
- Updated dependencies [d127ff0]
|
|
2225
|
+
- Updated dependencies [9b86cf6]
|
|
2226
|
+
- Updated dependencies [8825a06]
|
|
2227
|
+
- Updated dependencies [5087ac6]
|
|
2228
|
+
- Updated dependencies [2d1ddf0]
|
|
2229
|
+
- Updated dependencies [354b00f]
|
|
2230
|
+
- Updated dependencies [3de535b]
|
|
2231
|
+
- Updated dependencies [fe2e15a]
|
|
2232
|
+
- Updated dependencies [c6b6bb4]
|
|
2233
|
+
- Updated dependencies [2f59da0]
|
|
2234
|
+
- Updated dependencies [8ad609c]
|
|
2235
|
+
- Updated dependencies [bbee302]
|
|
2236
|
+
- Updated dependencies [08863dd]
|
|
2237
|
+
- Updated dependencies [56664f5]
|
|
2238
|
+
- Updated dependencies [31cbe90]
|
|
2239
|
+
- Updated dependencies [90bbf25]
|
|
2240
|
+
- Updated dependencies [eb91eba]
|
|
2241
|
+
- Updated dependencies [42da73d]
|
|
2242
|
+
- Updated dependencies [643b7c7]
|
|
2243
|
+
- Updated dependencies [1a15893]
|
|
2244
|
+
- Updated dependencies [b70e534]
|
|
2245
|
+
- Updated dependencies [2233a85]
|
|
2246
|
+
- Updated dependencies [62dd69a]
|
|
2247
|
+
- Updated dependencies [e15e679]
|
|
2248
|
+
- Updated dependencies [2ab1257]
|
|
2249
|
+
- Updated dependencies [4cc4fb7]
|
|
2250
|
+
- Updated dependencies [2c26040]
|
|
2251
|
+
- Updated dependencies [f758cec]
|
|
2252
|
+
- Updated dependencies [78f0be8]
|
|
2253
|
+
- Updated dependencies [35f7fb4]
|
|
2254
|
+
- Updated dependencies [a5302c7]
|
|
2255
|
+
- Updated dependencies [7084313]
|
|
2256
|
+
- Updated dependencies [0e043d8]
|
|
2257
|
+
- Updated dependencies [dadd1ad]
|
|
2258
|
+
- Updated dependencies [2f2e63c]
|
|
2259
|
+
- Updated dependencies [486d526]
|
|
2260
|
+
- Updated dependencies [89d7b35]
|
|
2261
|
+
- Updated dependencies [85ec26d]
|
|
2262
|
+
- Updated dependencies [f6476fc]
|
|
2263
|
+
- Updated dependencies [4ac12ef]
|
|
2264
|
+
- Updated dependencies [b88f5e8]
|
|
2265
|
+
- Updated dependencies [42cc219]
|
|
2266
|
+
- Updated dependencies [d7e0b42]
|
|
2267
|
+
- Updated dependencies [3510e4a]
|
|
2268
|
+
- Updated dependencies [aa4b90d]
|
|
2269
|
+
- Updated dependencies [54299ca]
|
|
2270
|
+
- Updated dependencies [dc61def]
|
|
2271
|
+
- Updated dependencies [251e888]
|
|
2272
|
+
- Updated dependencies [183b4c4]
|
|
2273
|
+
- Updated dependencies [2fdb36e]
|
|
2274
|
+
- Updated dependencies [20526f5]
|
|
2275
|
+
- Updated dependencies [c5eef1d]
|
|
2276
|
+
- Updated dependencies [e0f300b]
|
|
2277
|
+
- Updated dependencies [761a0ba]
|
|
2278
|
+
- Updated dependencies [be87153]
|
|
2279
|
+
- Updated dependencies [60f0dd8]
|
|
2280
|
+
- Updated dependencies [a87c5cd]
|
|
2281
|
+
- Updated dependencies [a47f338]
|
|
2282
|
+
- Updated dependencies [2598216]
|
|
2283
|
+
- Updated dependencies [2c7e62d]
|
|
2284
|
+
- Updated dependencies [eb7613c]
|
|
2285
|
+
- Updated dependencies [ecc9110]
|
|
2286
|
+
- Updated dependencies [f7bd4e2]
|
|
2287
|
+
- Updated dependencies [361bd5b]
|
|
2288
|
+
- Updated dependencies [1818998]
|
|
2289
|
+
- Updated dependencies [09ee21c]
|
|
2290
|
+
- Updated dependencies [f549a0d]
|
|
2291
|
+
- Updated dependencies [3fc2e48]
|
|
2292
|
+
- Updated dependencies [e8f435c]
|
|
2293
|
+
- Updated dependencies [41610f6]
|
|
2294
|
+
- @objectstack/spec@17.0.0-rc.6
|
|
2295
|
+
|
|
3
2296
|
## 17.0.0-rc.5
|
|
4
2297
|
|
|
5
2298
|
### Patch Changes
|