DAO-2251: Deposit/withdraw buttons stay disabled after claim/redeem on BTC vault page#2119
Merged
Freshenext merged 9 commits intomainfrom Apr 16, 2026
Merged
DAO-2251: Deposit/withdraw buttons stay disabled after claim/redeem on BTC vault page#2119Freshenext merged 9 commits intomainfrom
Freshenext merged 9 commits intomainfrom
Conversation
TravellerOnTheRun
changed the title
cybervoid0
approved these changes
Apr 16, 2026
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
STORY-DAO-2251 Phase 1. - Add getBtcVaultActionEligibilityContracts for shared multicall descriptors - useActionEligibility reads contracts via the helper (same on-chain calls) - Invalidate active-requests-history and wagmi readContracts keys; drop unused action-eligibility key
STORY-DAO-2251 Phase 1. - Compose page after-refetch callbacks with useActionEligibility refetch in BtcVaultDashboard - Extend dashboard tests for refetch ordering and probe callbacks - Add phase 1 devlog
Sequential awaits between phase-1 and phase-2 contract reads could run before React recomputed phase-2 query inputs from fresh phase-1 data, so redeem visibility and claimable withdrawal could lag or clear incorrectly. Parallel refetch restores the prior safe ordering while still returning a Promise for callers that await completion.
Callers that chain parent refetch then eligibility need a refetch that fully settles on-chain derived reads before UI re-enables deposit and withdraw. Sequential vault and whitelist refetch avoids racing the mapper on partially updated data.
Centralizes executeTxFlow wiring, invalidation, post-success refetch, and busy-state handling (wagmi pending gap and holding busy until claimable props clear) so claim and redeem CTAs share one behavior.
Dashboard buttons delegate to the shared finalize hook and a single busy presentation (primary look without native disabled, tooltip on wrapper) so in-progress copy and accessibility stay consistent.
After finalize, parent refetch and action eligibility refetch run in order so deposit and withdraw controls do not stay disabled from stale eligibility while the vault page catches up.
Matches dashboard finalize behavior for claim-in-flight so the detail view does not treat the control as a fresh clickable claim while the same safety and messaging expectations apply.
Matches history and detail CTAs for the same claimRedeemNative flow.
Ken-li-iov
approved these changes
Apr 16, 2026
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
4 participants
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.
Why this exists
After someone claims shares from a settled deposit or redeems from a claimable withdrawal, the vault UI has to catch up with reality: what the contracts still consider claimable, what the indexer shows, and whether Deposit / Withdraw should unlock again. If refetches race each other or finish in an order that leaves derived state half-updated, users can see actions stuck disabled or Redeem vanishing until a hard refresh. That is confusing and looks like a broken vault.
Separately, wagmi’s pending flags do not always cover the whole hand-off from “user signed” to “receipt pending.” There is a short window where a button can look clickable again even though the flow is still running, which invites double submits and erodes trust.
What we optimized for
Consistent refetch semantics
The page-level “active requests” data is assembled from more than one read pass plus history. Waiting for one pass before starting the next can actually be wrong here: React may not have rebuilt the second batch of contract calls from the newest first-pass snapshot yet, so the follow-up refetch can run against stale inputs. Firing the related refetches together again matches the behavior that already worked in production and avoids subtle “redeem disappeared” regressions.
Eligibility that really means “ready”
Deposit and withdraw availability comes from vault multicall reads plus whitelist state. When a finalize succeeds, downstream code needs
refetch()to mean “all of that settled,” not “we kicked off work.” Vault reads are awaited before whitelist so the mapper does not briefly mix a new vault snapshot with an old whitelist result.One finalize story for claim and redeem
Dashboard claim and redeem are the same orchestration at the transaction layer. Centralizing that in one hook keeps invalidation, post-success refetch, and busy rules identical so fixes apply to both paths.
Busy UI that matches the risk
We keep the primary look during the flow but avoid native
disabled(which greys out and fights the “primary in progress” design), wrap for tooltip hit target, and track an explicit “user committed to this flow” bit across wagmi’s pending gap. We also hold busy until claimable props actually clear so the label does not snap back to “Claim shares” / “Redeem shares” for a frame while the parent is still catching up.Dashboard then detail
The dashboard wires post-finalize work so parent refetch finishes before action eligibility refetch, keeping the metrics row and the actions row in sync. The request detail page gets the same in-progress expectations so behavior matches what users see on the main vault screen.
Tracks DAO-2251.