refactor(predict): migrate buy flow to single-route architecture with controller state machine#27761
Conversation
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
a06f3b8 to
6c18385
Compare
Replace direct ToastService calls with messenger.publish using the existing ControllerEventToastBridge pattern. Add 'order' type to PredictTransactionEventType and handle confirmed/failed statuses in usePredictToastRegistrations. Also publish order failed event when depositAndOrder fails and the user is not on the buy screen. Delete utils/toasts.ts since all toast rendering now goes through the bridge.
Guard the order confirmed messenger event with !activeBuyOrder so it only fires when the buy screen is unmounted. When the user is on screen, usePredictBuyActions shows the toast directly via showOrderPlacedToast from usePredictPlaceOrder on the SUCCESS state transition.
Move order-related query invalidation out of PredictController. Reuse invalidation from usePredictPlaceOrder for on-screen success, and rely on transactionStatusChanged handling for background updates. Update tests and docs to match the new ownership.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
There are 3 total unresolved issues (including 1 from previous review).
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
When the user places a bet via predictWithAnyToken and navigates away, background deposit/order results now show actionable toasts: - Order success → "View" button navigates to market details - Deposit/order failure → "Try Again" button navigates to market details The controller event payload is extended with an optional `marketId` so the toast handler can route to the correct market. Buttons degrade gracefully when marketId is absent.
When a deposit-and-order completes in the background while the user is configuring a new bet, the background placeOrder call incorrectly updates the new bet's activeBuyOrder state — causing loading spinners, false success toasts, and auto-dismissal of the screen. Root cause: isCurrentActiveBuyOrder returned true when activeBuyOrder.transactionId was undefined, matching any incoming transactionId. Fix: return false instead, since an active order without a transactionId was never part of a deposit-order flow. Additional guards: - Only pass transactionId from handleConfirm for PAY_WITH_ANY_TOKEN flow - Use isExistingPendingOrder to prevent background re-entry into PAT branch - Defer pendingOrderPreviews cleanup to placeOrder finally block - Publish events via messenger when background order completes without matching the active order
🔍 Smart E2E Test Selection
click to see 🤖 AI reasoning detailsE2E Test Selection:
Tag Selection Rationale:
The Performance Test Selection: |
|
✅ E2E Fixture Validation — Schema is up to date |
|
Description
The Predict buy/order flow previously navigated between separate screens for preview, token selection, and deposit confirmation. This caused visible screen flicker and complex navigation state synchronization that led to multiple UX bugs (header flicker, input delay, stale deposit amounts, broken back-swipe behavior).
This PR migrates the entire buy flow to a single-route architecture where all order states (preview, token selection, deposit, order placement) are managed by
PredictControllerand rendered inline withinPredictBuyWithAnyToken. Key changes:ActiveOrderStateenum (PREVIEW → PAY_WITH_ANY_TOKEN → DEPOSITING → PLACE_ORDER → PLACING_ORDER → SUCCESS) with dedicated controller methods for each transition (initializeOrder,onConfirmOrder,onDepositOrder,onDepositOrderSuccess,onDepositOrderFailed,onOrderError,onOrderCancelled,onPlaceOrderEnd,onBuyPaymentTokenChange).PredictPayWithAnyTokenInfois now a headless component that syncs deposit amounts and payment tokens via effects, rather than living on a separate navigation screen.usePredictBuyBackSwipe,usePredictPayWithAnyToken,usePredictOrderTracking,usePredictPayWithAnyTokenTracking, and redirect/confirmation logic that drove screen transitions.usePredictBuyPreviewActions(reacts toactiveOrder.statechanges via effects),usePredictPaymentToken,usePredictActiveOrder,usePredictBuyInputState, andusePredictBuyConditions.PredictControllernow handlespredictDepositAndOrdertransaction status events directly (confirmed → place order, failed → retry, rejected → cancel).Net result: ~800 lines removed, eliminated screen flicker, and centralized order lifecycle in the controller instead of distributed across navigation hooks.
Changelog
CHANGELOG entry: null
Related issues
Fixes:
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Pre-merge reviewer checklist
Note
Low Risk
Mostly documentation and test-mock adjustments, plus a new error code mapping; low likelihood of runtime impact aside from any new code paths relying on the added error constant/i18n key.
Overview
Updates
Predict/README.mdwith detailed documentation of the newPredictBuyWithAnyTokensingle-route buy flow, including its controller-driven active order state machine, component breakdown, and hook responsibilities.Adjusts several Predict component tests to mock
usePredictActiveOrderas returning onlyactiveOrder(removing now-unused mocked methods), and extendsPREDICT_ERROR_CODES/getPredictErrorMessageswithPREVIEW_NOT_AVAILABLE.Written by Cursor Bugbot for commit 8c2e6fc. This will update automatically on new commits. Configure here.