This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.
Project Overview
ARCTIS is an AI operating environment for programmable money built on Arc Testnet.
Its Bridge flow coordinates wallet state, network validation, Circle bridge quotes, transaction preflight, and asynchronous execution.
Live application:
https://arctis-zeta.vercel.app/
Repository:
https://github.com/pawansatoshi/Arctis
Bug Fix or Performance Improvement
The Bridge flow had a subtle asynchronous race condition.
A bridge quote could be requested while the user was changing the amount or route. Because the operation was asynchronous, an older quote response could return after a newer request and overwrite the current state.
There was also a second race: repeated or overlapping execution paths could reach the bridge execution flow before the previous operation had completed.
In a financial transaction flow, this is more than a normal UI race.
The execution layer must never use stale transaction intent, and the same transaction must not be executed more than once because of overlapping asynchronous operations.
Root Cause
The original implementation relied on React state captured by asynchronous callbacks.
That created two related problems:
Stale quote race
An older estimateBridge() response could finish after a newer quote request and update state with obsolete quote information.
Duplicate execution race
More than one execution path could reach the bridge operation before the first operation had completed.
The Circle bridge itself was not the root cause. The problem was the application's client-side orchestration around asynchronous financial operations.
Code
The complete fix is available in this commit:
fix: stop duplicate bridge execution and stale quote races — d3a10816
The relevant Bridge implementation is in:
The execution lock is implemented here:
The transaction regression coverage is here:
My Improvements
I fixed the race at the application level rather than trying to hide it with UI timing.
1. Current state reference
The Bridge flow now keeps a reference to the latest session state.
This prevents asynchronous callbacks from relying on stale React closures.
2. Quote sequencing
Each quote request receives a sequence number.
A quote response is accepted only if it is still the newest request.
This means an old network response can finish normally without being allowed to overwrite a newer quote.
3. Single-flight execution
Bridge execution now uses a deterministic execution lock.
The lock is based on the wallet, execution mode, source/destination route, and amount.
If the same operation is already executing, another execution attempt is rejected instead of entering the bridge flow again.
4. Execution revalidation
The transaction is not allowed to cross the execution boundary using an old quote alone.
Before wallet approval, the flow performs the required validation and obtains current bridge information again.
The resulting execution pipeline is:
User intent → Quote → Network verification → Balance/gas preflight → Fresh quote → Fee validation → Wallet approval → Bridge execution
5. Safe release
The execution lock is released after the execution path completes or fails, preventing a failed transaction from permanently blocking future legitimate attempts.
Why This Matters
The important invariant after the fix is:
Only current, validated transaction state may cross the execution boundary.
This matters especially for financial interfaces because asynchronous timing should not determine which quote, amount, route, or transaction state reaches the wallet.
The fix makes the execution lifecycle deterministic:
Proposal → Quote → Preflight → Fresh quote → Human approval → Submitted → Processing → Confirmed/Failed
Regression Coverage
The repository contains transaction regression checks for the critical safeguards.
The regression coverage checks for:
- current session state handling
- quote sequencing
- execution locking
- execution lock release
- chain verification
- network switching
- transaction confirmation handling
- bridge safeguards
- Circle quote gating
Regression script:
https://github.com/pawansatoshi/Arctis/blob/main/scripts/transaction-regression.mjs
Verification
The latest ARCTIS production deployment is marked READY on Vercel.
Live application:
https://arctis-zeta.vercel.app/
The current production deployment was checked for recent runtime errors and had no errors in the available latest-hour runtime window.
The repository also contains a release QA gate covering:
- type checking
- build validation
- API validation
- persistence
- concurrency
- duplicate execution
- retry and timeout behavior
- security
- accessibility
- responsive behavior
- production smoke testing
Impact
This was a bug fix in an existing ARCTIS codebase, not a new feature.
The fix removes two classes of timing-dependent failures from the Bridge flow:
- stale quote/state races
- duplicate execution races
The result is a more deterministic and safer transaction pipeline without changing the intended Bridge user experience.
What Changed
Commit:
d3a10816 — fix: stop duplicate bridge execution and stale quote races
Primary Bridge code:
https://github.com/pawansatoshi/Arctis/blob/main/src/app/bridge/page.tsx
Execution lock:
https://github.com/pawansatoshi/Arctis/blob/main/src/lib/transaction/execution-lock.ts
Regression tests:
https://github.com/pawansatoshi/Arctis/blob/main/scripts/transaction-regression.mjs
Live Demo
https://arctis-zeta.vercel.app/
Repository
https://github.com/pawansatoshi/Arctis
Final Takeaway
A transaction interface can look completely correct while still having a dangerous asynchronous race underneath.
The ARCTIS Bridge bug was caused by stale quote responses and overlapping execution paths.
The fix makes quote state current, execution single-flight, and transaction state revalidated before wallet approval.
The key engineering principle is simple:
Do not let asynchronous timing decide what financial transaction state gets executed.
Top comments (0)