Reduce polling latency from 1s fixed to 100ms progressive#61
Open
runnerelectrode wants to merge 3 commits intokenny019:devfrom
Open
Reduce polling latency from 1s fixed to 100ms progressive#61runnerelectrode wants to merge 3 commits intokenny019:devfrom
runnerelectrode wants to merge 3 commits intokenny019:devfrom
Conversation
Server benchmarks show order processing takes ~200ms, but the frontend used a fixed 1000ms sleep between retry polls. This added up to 5-30s of unnecessary wait time during trade settlement. Changes: - helpers.ts: replace fixed delay with progressive backoff (starts at base delay, grows 1.2x per attempt, caps at base*10). Remove noisy console.log on every retry attempt. - zk/trade.ts: reduce base retry delay from 1000ms to 100ms for all settleOrder, settleOrderSltp, and cancelZkOrder polling loops. - zk/account.ts: reduce base retry delay from 1000ms to 100ms for UTXO and output queries. Polling schedule (100ms base): 100 → 120 → 144 → 173 → ... → 1000ms cap vs old: 1000ms fixed on every attempt. No changes to rendering logic, component state, or API response formats.
|
@runnerelectrode is attempting to deploy a commit to the kenny019's projects Team on Vercel. A member of the Team first needs to authorize it. |
The open order flow was bottlenecked by waitForUtxoUpdate which had a hardcoded 5s minimum wait and 1s poll interval. Server benchmarks show UTXO updates are available in ~1.5-3s, so the 5s floor was wasting time. Changes: - waitForUtxoUpdate.ts: reduce min wait 5000ms -> 1500ms, poll interval 1000ms -> 200ms - market.client.tsx: reduce transaction hash retry delay 1000ms -> 100ms - limit.client.tsx: reduce transaction hash retry delay 1000ms -> 100ms
The open order flow has 3 sequential phases that take several seconds each, but the UI only showed a single "Placing order" toast. Users had no feedback during the ~10s wait. Now shows: Step 1/3: Preparing account → Transfer broadcast → on-chain confirmation Step 2/3: Submitting order → sending to relayer Step 3/3: Confirming order → waiting for fill confirmation Applied to both market and limit order forms.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Server-side benchmarks show the relayer processes trades in ~200ms, but the frontend used a fixed 1000ms sleep between retry polls, adding 5-30s of unnecessary wait time during trade operations.
Changes
lib/helpers.ts: Replace fixed delay with progressive backoff (100ms → 120ms → 144ms → ... → 1000ms cap). Remove noisyconsole.logon every retry.lib/zk/trade.ts: Base retry delay1000ms → 100msfor settle, SLTP, and cancel flowslib/zk/account.ts: Base retry delay1000ms → 100msfor UTXO and output queriesExpected improvement
Why this is safe
base * 10 = 1000ms)retry()function signature is unchanged — existing callers unaffectedTest plan