fix: enhance progress bar logic with completion delays and step staging

[fairlighteth]

Summary

Fixes #7274

Also addresses #6642 and #6915

Tightens the order progress bar state handling so it stays in the correct step order across retries, fast fills, reloads, bridge-status refreshes, approval/
allowance lag edge cases, and large-mobile animation rendering.

This change specifically:

• Prevents the bar from going back to step 1 after it has already moved past the initial state
• Ensures fast completion paths still show Executing when appropriate, but do not incorrectly jump from step 1 straight to step 3
• Handles backend retry flows like ACTIVE -> EXECUTING -> OPEN -> TRADED as 2 -> 3 -> 2 -> 3 -> 4
• Guards delayed completion timers so they cannot overwrite newer state or recreate pruned state
• Keeps recently untracked progress-bar state alive briefly so completion/retry transitions can finish, then prunes it automatically
• Preserves the current bridge progress step if bridge context briefly disappears during reload/reconnects
• Stops temporary allowance/balance lag from showing the Price change / UNFILLABLE screen in the progress bar
• Keeps the approval/permit race case on the normal batching/searching flow instead of showing a misleading price-change message
• Makes the debug playground behave much closer to production, including production-like timing rules and a static-step preview mode
• Fixes full-width progress-bar Lottie rendering on large mobile devices so steps like Executing do not show awkward empty top/bottom space, while smaller helper
  animations like the expired clock remain unscaled

To Test

1. Place an ETH-flow order and watch the progress bar through the full lifecycle

• It should not go from step 2 back to step 1 once it has already left the initial state
• If the backend goes ACTIVE -> EXECUTING -> OPEN -> TRADED, the UI should show step 2 -> step 3 -> step 2 (retry/error) -> step 3 -> step 4
• If the backend goes ACTIVE -> OPEN -> TRADED, the UI should still show step 2 -> step 2 (still searching) -> step 3 -> step 4
• If the order completes quickly after step 2, it should still show Executing before Executed
• It should not jump directly from step 2 to Executed

2. Place a regular order and watch the progress bar through the full lifecycle

• The normal happy path should still be step 1 -> step 2 -> step 3 -> step 4
• If the backend retries after EXECUTING, the UI may go from step 3 back to step 2, but not back to step 1
• After a retry, the order should show Executing again before the final executed state
• If a very fast fill is picked up before the bar leaves step 1, it should not incorrectly jump straight to step 3

3. Check approval / allowance lag behavior

• After approval / permit / bundled Safe approval flows, the progress bar should start with step 1 and continue into the normal batching/searching flow
• It should not show the Price change screen when the real issue is temporary allowance or balance lag
• The Price change screen should still appear for true price-derived unfillable cases

4. Reload or reopen the app while an order is near completion

• If the fulfilled widget event is missed on reload, the UI should not sit on step 2 for an extra 5 seconds before showing Executing
• Completion-driven staging should move to Executing immediately, then finish
• A delayed completion timer should not resurrect stale progress after the order state was already changed or pruned

5. Check bridge-order behavior around reconnects / refreshes

• If a bridge order is already in a bridge step, a temporary bridge-context reload should not move it backward to Executing
• If bridge context comes back, the bar should continue from the correct bridge step

6. Regression-check delayed timer behavior

• If the order state changes during the delayed completion window, the old delayed timer should not overwrite the newer state
• If the order disappears from tracked progress-bar state, the delayed timer should not recreate it
• If the last tracked order finishes, stale retained progress should still self-prune after the grace period without requiring another rerender
• Progress-bar pruning should not cause unrelated order observers to rerender on each tick

7. Debug playground

• Open /debug/progress-bar?debugProgressBar=1
• In Scenario playback mode, canned sequences should respect the same 5s minimum-step rule and priority-step exceptions as production
• In Static step preview mode, the selected step should stay pinned with no progression so animations/copy/layout can be inspected
• Countdown scenarios should start from 15
• The Issue Progress bar starts with ‘Price change’ message #6642 fixed: approval lag stays on batching/searching scenario should stay on normal batching/searching steps and not show Price change

8. Large-mobile rendering

• On a large mobile device or simulator, Static step preview -> step 3 executing should fill the artwork area without obvious empty top/bottom padding
• The same step should not introduce new left/right gutters on medium mobile widths
• Static step preview -> expired should keep the clock badge correctly sized and not crop or distort it

Background

The main bug was a frontend state-machine issue: after the progress bar had already advanced, an OPEN status could still send it back to the initial step because
the fallback check was using stale step history.

While fixing that, a few related edge cases became clear:

• fast completion paths could skip Executing entirely
• delayed completion timers could apply stale final states after newer updates
• completion-driven Executing staging could still be held behind the generic 5s minimum-step delay on reload/startup paths
• retry flows after EXECUTING -> OPEN needed to show Executing again before the final executed state
• bridge orders could briefly jump backward if bridge context disappeared during reload/reconnect
• recently untracked progress state needed a short retention window so completion/retry transitions could finish, but that retention also needed to self-expire and
  stay isolated from unrelated observer rerenders
• the progress bar was treating temporary allowance/balance lag the same as true price-derived unfillable states, which caused misleading Price change screens in
  approval/permit races
• the large-mobile layout exposed extra whitespace in some full-width progress-bar animations because the card stayed on the short mobile height while wider phone
  widths made the animation canvas more obvious

This PR fixes those behaviors and adds targeted regression coverage around retry sequences, immediate completion staging, bridge-context reloads, stale/pruned
timer safety, pruner isolation, approval/allowance lag, and large-mobile animation rendering.

It also adds a temporary debug playground route for QA that can:

• replay canned backend/status sequences with production-like timing rules
• pin a single static step to inspect animations, copy, and layout without progression

Follow-up:

• useGetExecutingOrderState() still subscribes to the full ordersProgressBarStateAtom, so progress updates for one order can rerender other order observers. That
  is a pre-existing performance concern and should be handled in a small follow-up PR rather than expanding the scope of this bugfix.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
cowfi	Ready	Preview	Apr 10, 2026 2:53pm
explorer-dev	Ready	Preview	Apr 10, 2026 2:53pm
swap-dev	Ready	Preview	Apr 10, 2026 2:53pm
widget-configurator	Ready	Preview	Apr 10, 2026 2:53pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
cosmos	Ignored		Apr 10, 2026 2:53pm
sdk-tools	Ignored	Preview	Apr 10, 2026 2:53pm

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 3b3bd240-e930-4a8d-a9b9-990208532117

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/progressbar-states

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[elena-zh]

Hey @fairlighteth , thank you, looks waaaay better, however, for this order

steps were 1-2-3-2-4.
E.g., the order from 'executing' went back to the 'still searching' (open), and then went to 'traded' without 'executing'

Could you please take a look at it?

[fairlighteth]

@elena-zh for debugging purposes only -> https://swap-dev-git-fix-progressbar-states-cowswap-dev.vercel.app/#/debug/progress-bar?debugProgressBar=1

[elena-zh]

Hey @fairlighteth , great, great job!

There is only one nitpick with 'real' order for this scenario:

when a status is changed from 'active to open' after failure, I don't see the test 'a new competition'

I see the regular  'competition started'

Could you please take a look at it? For the reference, here is the orderID (if needed) with which I faced this issue.

Thank you!