Uh oh!
There was an error while loading. Please reload this page.
fix(console): API Discovery Storage group reads the canonical storage slot first - #5290
Merged
os-support-ai merged 2 commits intoAug 19, 2026
Merged
Conversation
…e` slot first (#5286) `useApiDiscovery`'s `SERVICE_ENDPOINT_CATALOG` looked the Storage service up in `/discovery`'s `services` map by the deprecated `file-storage` key only. The framework's #9683 ruling made `storage` the canonical `CoreServiceName` slot and mirrors `file-storage` byte-equal alongside it for v17's lifetime. Read `services.storage` first, fall back to `services['file-storage']` — both spellings keep resolving the group while the alias lives. The catalog's own key stays `file-storage`: the locally pinned `@objectstack/spec` has not published `storage` as a `CoreServiceName` member yet (verified against the installed package), so re-keying now would fail the existing #4240 tripwire against real, currently-installed types. A `DEPRECATED_SERVICE_SLOT_ALIASES` table bridges the gap until that dependency catches up. Refs objectstack-ai/objectstack#9683, objectstack-ai/objectstack#9819.
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
This was referenced Aug 19, 2026
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
This was referenced Aug 19, 2026
os-support-ai
marked this pull request as ready for review
August 19, 2026 12:10
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#5286
What
apps/console/src/pages/developer/hooks/useApiDiscovery.tslooked the Storageservice slot up in
/discovery'sservicesmap by the deprecatedfile-storagekey only. The framework's #9683 ruling(objectstack-ai/objectstack#9683, merged as objectstack-ai/objectstack#9820)
made
storagethe canonicalCoreServiceNameslot and keptfile-storagemirrored, byte-equal, alongside it for
@objectstack/spec's v17 lifetime.This is the consumer-side rename follow-up: the lookup now reads
services.storagefirst and falls back toservices['file-storage'], so theStorage group renders from either spelling — the canonical one when the
backend has deployed the #9683 mirror row, and the deprecated one for a
backend that has not.
Why the catalog key itself did not move
SERVICE_ENDPOINT_CATALOGstays keyed byfile-storage, not re-keyed tostorage. Verified directly against the installed dependency (not assumed):the locally pinned
@objectstack/spec@17.0.0has not publishedstorageasa
CoreServiceNamemember yet —Re-keying the catalog to
storagenow would fail the existingSERVICE_ENDPOINT_CATALOG keys are canonical service-slot namestripwire(objectui#4240) against these real, currently-installed types — not because
the framework's rename is wrong, but because this repository's dependency has
not caught up to it yet. A new
DEPRECATED_SERVICE_SLOT_ALIASEStable bridgesthe gap: it is keyed by the catalog's own (still-deprecated) key and maps it to
the canonical discovery key to read first. Re-key the catalog entry to
storageand delete that table once@objectstack/specpublishes the newenum member and this repo's lockfile picks it up.
Tests
useApiDiscovery.test.tsnow pins both spellings:storageslot resolves the Storage group (new — this is whata hard swap to
storage-only would also pass);file-storageslot still resolves it while the v17 aliaslives (this is what a hard swap would FAIL — the case the fix shape rules
out);
order, not a merge/OR of the two);
storagewhile/discoverynames the slotfile-storage, so the fail-closed branch hides 3 endpoints #4240 isotherwise unchanged;
assertion does not depend on the
@objectstack/specdependency bump notedabove.
Reverse verification (restore the pre-fix hook, keep the new tests): predicted
3 of 14 would go red — the two new canonical-slot assertions (nothing to
resolve against the old file-storage-only lookup) and the new alias-table pin
(the export does not exist pre-fix) — with the rest staying green. Observed
exactly that (
14 tests | 3 failed, the 3 named above), then restored thefix and re-ran clean (
14 passed).Also run at the same HEAD (
47cc35bfc):pnpm --filter '@object-ui/console' type-check(exit 0),pnpm --filter '@object-ui/console' lint(0 errors,200 pre-existing warnings unrelated to this diff),
node scripts/check-control-bytes.mjs(OK),node scripts/check-changeset-presence.mjs(declares.changeset/storage-canonical-slot-key-console.md). All commands run fromthe repo root per AGENTS.md's vitest-invocation guard.
Cross-repo
Named reader in the framework's retirement ledger:
objectstack-ai/objectstack#9819 — landing this un-blocks one line of that
ledger (not a closing reference; the ledger line lives in that repo).
Scope
No accept-set change:
SERVICE_ENDPOINT_CATALOG's key vocabulary isunchanged, only the discovery lookup for the one aliased slot.
Generated by Claude Code