You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit ee4291e
Browse filesBrowse the repository at this point in the historyBrowse files
fix(runtime): refuse a non-array packages in resolveArtifactCollections
A release artifact's `packages` that is present but not an array ({}, 0,
'x') is malformed, not absent. The runtime collection reader used to hand
such an artifact back by identity; it now treats only undefined/null as
absent and lets resolveArtifactPackageOrder raise INVALID_ARTIFACT_PACKAGES.
The rule is stated once, beside AssembledPackageBodySchema; the core
resolver, the runtime reader and both plugin readers point at it. The
plugin-security reader drops its private guard (measured result-equal);
the plugin-dev reader keeps its guard, limited to the absent branch, with
the measured reason at the site.
Claude-Session: https://claude.ai/code/session_01Sfe5YjBLwB9J3y8fvm2xq1
Co-authored-by: Claude <noreply@anthropic.com>
A release artifact whose `packages` is present but is not an array (`{}`, `0`, `'x'`) is now refused by the runtime's collection reader too, as `INVALID_ARTIFACT_PACKAGES` (ADR-0112, `status: 422`) (#15293).
6
+
7
+
Clause-②: no
8
+
9
+
`packages` is declared as an array of package entries (`ObjectStackDefinitionSchema.packages: z.array(ArtifactPackageSchema).optional()`), and the rule is now written down once, beside `AssembledPackageBodySchema` in `@objectstack/spec`: an absent `packages` means a single-package artifact, and any other non-array value is malformed and refused. `resolveArtifactPackageOrder` in `@objectstack/core` already refused it, and so did the i18n detector in `@objectstack/plugin-dev` and the default-permission-set reader in `@objectstack/plugin-security`. The runtime's collection reader was the one that answered differently: it handed such an artifact back unchanged and read its collections off the top level.
10
+
11
+
-**What changes**: `AppPlugin` reads its collections in `start()`, and `start()` now raises the same refusal `init()` already raised through the kernel's `manifest` service. Under `os dev`, `DevPlugin`'s child-`start()` loop logs it on its `error` line, where before the app started on its top-level collections alone. `createStandaloneStack` now refuses such an artifact while it builds the stack. Before, the refusal came later, when the app registered with the `manifest` service. `loadArtifactBundle`'s runtime-module merge reports it through its existing `warn` line and skips the merge, as it already does for a malformed `packages[]` entry.
12
+
-**What does not change**: an absent `packages`, and `packages: null`, still return the caller's own object by identity. A well-formed `packages[]` resolves exactly as before.
13
+
-**Fix**: remove the `packages` key for a single-package artifact, or make it an array of `{ manifest: … }` entries.
0 commit comments