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 8f1851e
Browse filesBrowse the repository at this point in the historyBrowse files
fix(engine-core): propagate package disable to metadata listings and the data plane (#7557) (#7700)
* fix(engine-core): propagate package disable to metadata listings and the data plane (#7557)
Half (A) of #7557: a package at `status: 'disabled'` had its nav and views
correctly dropped while `GET /api/v1/data/<object>` still answered 200 with
every row and `GET /meta/objects` still listed the object. Reproduced on a
real server before the change, over two disable/enable cycles.
Both skips were deliberate and gave the same reason — filtering objects
"would break data queries that depend on their schema". That conflated two
classes of reader, which are now separated:
* RESOLUTION readers keep serving. `registry.getObject` and
`registry.listItems('object')` still return a disabled package's objects;
migrations, cross-package references and the runtime authoring gate's
object universe all resolve through them. Disable stays reversible and
still destroys no data.
* API readers now stop. `getMetaItems` drops the `object`/`objects`
exemption (`package` is still never filtered, or a disable could never be
undone), and the data plane refuses in `assertObjectRegistered` — the one
gate every findData/getData entry point funnels through.
The data-plane refusal is loud rather than silent: a new
`OBJECT_PACKAGE_DISABLED` / 404 naming the cause and the remedy, instead of a
bare `OBJECT_NOT_FOUND` that sends a caller hunting for a typo. The 404 status
matches the closest sibling switch, `OBJECT_API_DISABLED`. Registered in the
ADR-0112 ledger.
`SchemaRegistry.isObjectPackageDisabled` resolves names through the same
`resolveObjectKey` the read path uses, so the gate and the read cannot
disagree about which contributor entry a bare name addresses (#6808's lesson).
Half (B), envelope only: `DELETE /packages/:id` on the dispatcher door stated
`success: true` unconditionally and forwarded the protocol's own
`{ success: false, deletedCount: 0 }` underneath it. Per-item failures now
answer 400 `PACKAGE_DELETE_PARTIAL` with the failed items and the uninstall
cleanup outcomes, matching the direct-mount REST door of the same route —
including its carve-out that zero metadata rows is still a successful
uninstall. The remaining half of (B), a persistence defect where
`deletePackage` finds zero rows while package-bound rows exist, is reported
for transfer rather than patched from the consumer side.
Tests: one table-driven test walks every reader of the disable predicate and
states which class each belongs to, so a new reader that forgets to consult it
fails there rather than in one test per surface. Both halves reverse-verified
independently.
* chore(spec): regenerate reference docs for the new error code (#7557)
`OBJECT_PACKAGE_DISABLED` joins the ADR-0112 ledger, so the generated
`content/docs/references/` pages move with it: the ledger page gains the
entry, and every page rendering the ErrorCode union bumps its
"+259 more" count to "+260". Regenerated with
`gen:schema && gen:docs`, never hand-edited.
Release-owned `content/docs/releases/` is untouched.
---------
Co-authored-by: Claude <noreply@anthropic.com>
|**data**|`{ name: string; title?: string; measures: object[]; dimensions: object[] }[]`| ✅ | Available cubes, each as the `CubeMeta` discovery projection — the cube name, its title, and the measures/dimensions a client may name in a query. A bare array: there is no `cubes` wrapper object, and no cube `sql` is published. |
50
50
@@ -79,7 +79,7 @@ const result = AnalyticsEndpoint.parse(data);
79
79
| Property | Type | Required | Description |
80
80
| :--- | :--- | :--- | :--- |
81
81
|**success**|`boolean`| ✅ | Operation success status |
0 commit comments