fix(console): marketplace read cloud errors seven different ways — two break on the conversion, two are broken today (cloud#944) - #3086
Merged
Conversation
…o of them break on the conversion, two are broken today (cloud#944)
`service-cloud` answers failures in two shapes and is mid-conversion between
them (cloud#944):
{ success: false, error: '<message>' } today, via `fail()`
{ success: false, error: { code, message } } the declared envelope
`marketplaceApi.ts` hand-rolled that read at seven call sites, in four
different ways. The spread was not harmless in either direction:
- TWO read `payload?.error` bare with no nested fallback. When the producer
converts, those receive an OBJECT where the surrounding type declares
`error?: string`. An object handed to a toast as a React child crashes the
page — objectstack#3913's exact symptom, which the actions route already
carries `interpretActionResponse` to prevent. Nothing typed catches it:
these payloads are `any`.
- TWO read only the nested form, so against a server shipping TODAY they
find nothing and degrade a real explanation into a bare status code.
So this is not only preparation. Two of the four defects are live: those sites
are swallowing messages users should be seeing right now.
One `readApiError(payload, res)` replaces all seven. It reads nested first,
then `fail()`'s bare string, then a top-level `message`, then `statusText`, and
it guarantees a STRING back — an unexpected shape degrades to the code rather
than travelling onward as an object, which is the property the two bare sites
needed. The `installPackage` site keeps its own `innerFailed` branch: that one
reads a different object (the HTTP-200-with-`data.success: false` shape), so
only its outer read is shared.
Tests pin all four dialects reading the same, the sibling-`code` form
(`failWithCode`), and that an unexpected shape can never leave as an object.
This is the consumer half of cloud#944's conversion order, and the reason that
order exists: the producer flip is two functions in
`cloud-artifact-helpers.ts`, but doing it before this lands breaks the console.
Same shape as objectui#2992 teaching `useAgents` four shapes before the
/ai/agents producers moved (objectstack#4053) — consumer first, then the server
converts on its own schedule.
Verified: 8 new tests pass, app-shell tsc clean. No behavior change against any
server shipping today except the two sites that start showing their message.
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BZaiYNM5igzGk6JiibjShb
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
os-zhuang
marked this pull request as ready for review
July 31, 2026 02:30
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 free
to 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.
The consumer half of cloud#944's conversion order. Companion: cloud#946.
What's wrong
service-cloudanswers failures in two shapes and is mid-conversion between them:marketplaceApi.tshand-rolled that read at seven call sites, in four different ways. The spread is not harmless in either direction:payload?.error || \HTTP ${res.status}``error?: stringpayload?.error?.message ?? statusTextpayload?.error?.message ?? payload?.error ?? …So two of the four defects are live. Those sites are swallowing messages users should be seeing right now — this isn't only preparation.
And the two bare ones are the blocking kind: an object handed to
toast.error()as a React child crashes the page. That's objectstack#3913's exact symptom, which the actions route already carriesinterpretActionResponseto prevent. Nothing typed catches it — these payloads areany.The change
One
readApiError(payload, res)replaces all seven. Nested first, thenfail()'s bare string, then a top-levelmessage, thenstatusText— and it guarantees a string back, degrading an unexpected shape to the code rather than letting it travel onward as an object. That guarantee is what the two bare sites actually needed.installPackagekeeps its owninnerFailedbranch: that one reads a different object (the HTTP-200-with-data.success: falseshape), so only its outer read is shared.Why the consumer moves first
The producer flip is genuinely small — two functions in
cloud-artifact-helpers.ts, ~340 bodies. Doing it before this lands breaks the console.Same shape as objectui#2992 teaching
useAgentsfour shapes before the/ai/agentsproducers moved (objectstack#4053): the consumer learns every dialect, then the server converts on its own schedule instead of landing in lockstep with a console release.Verification
readApiErrortests (new)code, and "never returns an object"tsc --noEmit(app-shell)No behavior change against any server shipping today, except the two sites that start showing their message instead of a status code.
Generated by Claude Code