Pull changes into makeswift#2683
Conversation
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
|
|
||
| return action(state, formData); | ||
| }, |
There was a problem hiding this comment.
Bug: useActionState creates an unresolvable Promise when action is a string, causing the form to hang in a pending state.
Severity: HIGH | Confidence: 1.00
🔍 Detailed Analysis
The useActionState hook in core/vibes/soul/sections/cart/client.tsx creates a Promise that never settles when the action is a string. The new Promise<void>(() => { window.location.assign(action); }) executor function is missing the resolve() callback. This causes the async function to never return, leaving the form action in a perpetual "pending" state. Consequently, the UI's loading indicator remains active indefinitely during page navigation.
💡 Suggested Fix
When action is a string, directly call window.location.assign(action) and return null without awaiting a Promise.
🤖 Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: core/vibes/soul/sections/cart/client.tsx#L643-L645
Potential issue: The `useActionState` hook in `core/vibes/soul/sections/cart/client.tsx`
creates a Promise that never settles when the `action` is a string. The `new
Promise<void>(() => { window.location.assign(action); })` executor function is missing
the `resolve()` callback. This causes the async function to never return, leaving the
form action in a perpetual "pending" state. Consequently, the UI's loading indicator
remains active indefinitely during page navigation.
Did we get this right? 👍 / 👎 to inform future reviews.
Reference_id: 2624952
There was a problem hiding this comment.
This is intended and not a bug. This happens when the page is being navigated away from, so that the checkout button can have a pending state.
There was a problem hiding this comment.
We actually shouldn't have a 1.3.1 changelog entry on integrations/makeswift yet, since the version hasn't been bumped. Let's remove this from the PR, as it will be created automatically as a result of step 3 (when you open a second PR into integrations/makeswift with the changeset linking to the 1.3.1 entry on canary.
0a7f6d4 to
c2e23c0
Compare
c2e23c0 to
c9c800b
Compare
3 participants
What/Why?
Pull the updated canary changes into makeswift
Testing
n/a
Migration
Copy all changes from this PR