fix(axios-client): stop Activity Monitor sticking on "Pending" after a 200#201
Open
netanelgilad wants to merge 1 commit into
Open
fix(axios-client): stop Activity Monitor sticking on "Pending" after a 200#201netanelgilad wants to merge 1 commit into
netanelgilad wants to merge 1 commit into
Conversation
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
🚀 Package Preview Available!Install this PR's preview build with npm: npm i @base44-preview/sdk@0.8.32-pr.201.f1de9afPrefer not to change any import paths? Install using npm alias so your code still imports npm i "@base44/sdk@npm:@base44-preview/sdk@0.8.32-pr.201.f1de9af"Or add it to your {
"dependencies": {
"@base44/sdk": "npm:@base44-preview/sdk@0.8.32-pr.201.f1de9af"
}
}
Preview published to npm registry — try new features instantly! |
…a 200 The Activity Monitor (host builder) creates a "Pending" entry on api-request-start and resolves it on api-request-end. Both are sent to the parent window via postMessage, which serializes with the structured-clone algorithm. When a request/response body isn't structured-cloneable (e.g. a backend function whose response carries a function, stream, or other host object), postMessage throws DataCloneError synchronously. On the success path that throw was swallowed by an empty try/catch, so api-request-end was never delivered and the request stayed "Pending" forever despite returning 200. The error path posted nothing at all. Route all activity messages through postActivityMessage, which retries with a JSON-sanitized payload (toSerializable) when the raw post throws, so the status code is always delivered while the real body is preserved when cloneable. Also post api-request-end on the error path so failed requests resolve too. Mirrors the platform-side fix in apper (builder axiosClient). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TMZivSDxbkghHKnS1iyxvs
f1d7c0e to
c3e12bc
Compare
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
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.
What
Mirror of the platform-side fix in apper (PR base44-dev/apper#12518). The host builder's Activity Monitor creates a "Pending" entry on
api-request-startand resolves it onapi-request-end. Both are sent to the parent window viapostMessage, which serializes with the structured-clone algorithm.When a request/response body isn't structured-cloneable (a function, stream, or other host object),
postMessagethrowsDataCloneErrorsynchronously:try/catch, soapi-request-endwas never delivered → the request stayed "Pending" forever despite returning 200.api-request-endat all, so failed requests also stuck on "Pending".Fix
Route all activity messages through
postActivityMessage, which retries with a JSON-sanitized payload (toSerializable) when the raw post throws — the status code is always delivered, the real body is preserved when cloneable. Also emitapi-request-endon the error path.Tests
New
tests/unit/axios-client.test.tssimulates the browser (postMessagerunsstructuredClone) and asserts the end event is still delivered for a non-cloneable 200, plustoSerializablecoverage. The guard fails on the old swallow-only code and passes with the fix. Full unit suite (159) + typecheck green.🤖 Generated with Claude Code
https://claude.ai/code/session_01TMZivSDxbkghHKnS1iyxvs