refactor: handle intent orders in fetch bridge tx function #7756
Conversation
oscarwroche
force-pushed
the
refactor/fetch_bridge_status_intent_refactoring
branch
from
ab4908f to
c7c0722
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
oscarwroche
force-pushed
the
refactor/fetch_bridge_status_intent_refactoring
branch
from
67c420e to
073d57e
Compare
oscarwroche
force-pushed
the
refactor/fetch_bridge_status_intent_refactoring
branch
2 times, most recently
from
23571af to
829cb08
Compare
oscarwroche
force-pushed
the
refactor/fetch_bridge_status_intent_refactoring
branch
from
829cb08 to
e5bf7c2
Compare
| }); | ||
| } | ||
| }; | ||
| } |
There was a problem hiding this comment.
Single-method class adds unnecessary indirection
Low Severity
The IntentStatusManager class contains only one method (syncTransactionFromIntentStatus), is instantiated once, and called from a single location. The class stores messenger and updateTransactionFn in its constructor just to pass them to its only method. A standalone function accepting these dependencies as parameters would achieve the same result with less abstraction and no additional file needed.
Additional Locations (1)
oscarwroche
force-pushed
the
refactor/fetch_bridge_status_intent_refactoring
branch
from
84393f1 to
6dbe727
Compare
| validateIntentOrderResponse, | ||
| } from './validators'; | ||
| import type { FetchFunction } from '../types'; | ||
| import type { FetchFunction, StatusResponse } from '../types'; |
There was a problem hiding this comment.
Duplicated getClientIdHeader utility function exists
Low Severity
The getClientIdHeader function in intent-api.ts is a duplicate of the identical function already defined in bridge-status.ts. Both functions take a clientId string and return an object with an X-Client-Id header. The existing function in bridge-status.ts could be imported and reused instead of defining a new identical function.
| "srcTxHashes": Array [ | ||
| "0xsrcTxHash1", | ||
| ], |
There was a problem hiding this comment.
I don't see srcTxHashes being used in the mobile codebase. And the only usage I see in the controller is for updating the history item. Can this field be removed?
|
|
||
| export const waitForTxConfirmation = async ( | ||
| messenger: BridgeStatusControllerMessenger, | ||
| txId: string, | ||
| { | ||
| timeoutMs = 5 * 60_000, | ||
| pollMs = 3_000, | ||
| }: { timeoutMs?: number; pollMs?: number } = {}, | ||
| ): Promise<TransactionMeta> => { | ||
| const start = Date.now(); | ||
| while (true) { | ||
| const { transactions } = messenger.call('TransactionController:getState'); | ||
| const meta = transactions.find((tx: TransactionMeta) => tx.id === txId); | ||
|
|
||
| if (meta) { | ||
| if (meta.status === TransactionStatus.confirmed) { | ||
| return meta; | ||
| } | ||
| if ( | ||
| meta.status === TransactionStatus.failed || | ||
| meta.status === TransactionStatus.dropped || | ||
| meta.status === TransactionStatus.rejected | ||
| ) { | ||
| throw new Error('Approval transaction did not confirm'); | ||
| } | ||
| } | ||
|
|
||
| if (Date.now() - start > timeoutMs) { | ||
| throw new Error('Timed out waiting for approval confirmation'); | ||
| } | ||
|
|
||
| await new Promise((resolve) => setTimeout(resolve, pollMs)); | ||
| } | ||
| }; |
There was a problem hiding this comment.
Nice! Can you move this to transactions.ts? that's where the TransactionController-related utils are
| try { | ||
| // Use 'intent:' prefix for intent transactions | ||
| const bridgeHistoryKey = `intent:${orderUid}`; | ||
| // Use orderId as the history key for intent transactions | ||
| const bridgeHistoryKey = orderUid; |
There was a problem hiding this comment.
This is a breaking change btw - existing intent txHistory items will need to be migrated to use the new key format
Explanation
Removed the dedicated intent polling path and folded intent updates into the existing bridge status polling flow. Intent status translation now lives in
intent-apito align withfetchBridgeTxStatusresponses, with shared handling for completion, failure, and transaction sync. Updated and added tests to cover the new translation and intent polling behavior.References
Checklist
Note
Medium Risk
Refactors core polling and state-keying for intent orders, which could affect persisted
txHistorylookups, polling lifecycle, and TransactionController sync behavior. Risk is mitigated by expanded unit tests, but regressions would surface as missing/incorrect status updates.Overview
Intent order handling is folded into the main
#fetchBridgeTxStatusflow, removing the dedicated intent polling path and translating intent API responses via the newtranslateIntentOrderToBridgeStatushelper inintent-api.Intent history items are now keyed by
orderUid(nointent:prefix), and polling decides “intent vs bridge” based onquote.intent. Polling also merges and persistssrcTxHashes, and intent status updates now sync the underlying TransactionController transaction via the extractedIntentStatusManager.Common controller logic was extracted into
bridge-status-controller-helpers(history rekey + approval confirmation wait), and the test suite was updated/expanded accordingly; Jest coverage thresholds were raised.Written by Cursor Bugbot for commit 6dbe727. This will update automatically on new commits. Configure here.