Repository navigation
fix(pages): pass through any Response returned from page loaders - #37
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: abea7c0309
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
906d90e to
af14340
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: af143404b5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
af14340 to
ad156b7
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad156b71a8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Previously, handlePageGet only short-circuited for Response objects with status >= 300 (redirects, 4xx, 5xx). A loader returning a 200 Response (e.g. for content negotiation like Accept: text/markdown) would fall through to extractProps(), which crashes because it expects a plain object, not a Response. Now any Response returned from a loader is passed through directly, regardless of status code. This enables loaders to return custom responses for content negotiation, streaming, or other use cases. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ad156b7 to
e116244
Compare
…entical deploys (#37) * fix(api): retry CF asset session on plain-text response and dedupe identical deploys CF's WfP assets-upload-session API intermittently returns plain text ("Assets have already been uploaded") instead of JSON when all asset hashes already exist. This varies by edge node and causes deploys to fail with "Unexpected token 'A'" JSON parse errors. Two fixes: 1. Retry: createAssetUploadSession now retries up to 3 times with backoff (1s, 2s, 3s) when CF returns plain text. HTTP errors still fail immediately. 2. Dedupe: Before creating a deployment record, the deploy handler compares manifest + asset hashes + secrets state with the current live deployment. If identical, returns immediately without any CF API calls. This handles the common case of CI redeploying unchanged code (e.g. same commit daily). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(api): move dedupe before quota check, drop secrets comparison Address two review comments: 1. Move the identical-deploy fast path before the daily quota check so users at their deploy limit still get instant skips for unchanged deploys instead of 429. 2. Remove hasSecretsChangedSince from the dedupe gate. The secrets API already live-pushes values to the active worker via putWorkerSecret. If that push fails the user gets a 502 and should retry the secret PUT, not redeploy. Keeping the check caused unnecessary full deploys after every secret rotation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>


Previously, handlePageGet only short-circuited for Response objects
with status >= 300 (redirects, 4xx, 5xx). A loader returning a 200
Response (e.g. for content negotiation like Accept: text/markdown)
would fall through to extractProps(), which crashes because it
expects a plain object, not a Response.
Now any Response returned from a loader is passed through directly,
regardless of status code. This enables loaders to return custom
responses for content negotiation, streaming, or other use cases.
Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
Note
Medium Risk
Changes loader return-value handling so some
Responseobjects now bypass props extraction, which could affect existing loaders relying on previous behavior (especially around JSON/content-type detection). Adds runtime tracking of framework-generated responses, so mis-tagging could change whether a response is unwrapped vs returned directly.Overview
Page loaders can now return custom
Responses without crashing.handlePageGetnow passes through user-constructedResponses for redirects/errors and for non-JSON200responses (e.g. downloads/streams), while still extracting props from JSON responses for backward compatibility.Framework-generated responses are explicitly tracked.
convertReturnValuenow tags its created responses (via aWeakSet+isConvertedResponse) sohandlePageGetcan safely unwrap those into page props.Separately, the SSR renderer’s
serializePageDataswitches to a single regex-based escape pass for<,>,&, and Unicode line separators.Written by Cursor Bugbot for commit e116244. This will update automatically on new commits. Configure here.