Skip to content

feat(frontend): surface transaction states and typed errors - #53

Open
woahwhattheheck wants to merge 13 commits into
Secureflow-protocol:mainfrom
woahwhattheheck:fix/44-transaction-state-error-ux
Open

woahwhattheheck wants to merge 13 commits into
Secureflow-protocol:mainfrom
woahwhattheheck:fix/44-transaction-state-error-ux

Conversation

@woahwhattheheck

@woahwhattheheck woahwhattheheck commented Oct 6, 2026 •

Copy link
Copy Markdown

Closes #44

Summary

  • centralize SecureFlow transaction error guidance into typed, human-readable messages with suggested next actions;
  • surface explicit transaction progress through building, signing, pending, success, and failed states in milestone actions;
  • preserve transaction hashes across pending/timeout paths and check chain status before offering a safe retry, avoiding blind resubmission;
  • preserve a deterministic local transaction hash before RPC broadcast in the six issue-facing milestone methods; if the send response is lost after a possible broadcast, surface pending state with that hash and raise PendingTransactionError instead of enabling a blind retry;
  • keep explicit TRY_AGAIN_LATER responses retryable, while ambiguous post-broadcast transport failures become status-check-only through the preserved local hash;
  • isolate routed render failures with a React error boundary and remount that boundary on route identity change, so a failure on one route cannot pin the fallback after navigation;
  • report the signing phase immediately before both signing paths in startWork, submitMilestone, and resubmitMilestone.

Scope

Current carrier is intentionally bounded to the frontend acceptance surface in:

  • src/App.tsx
  • src/components/milestone-actions.tsx
  • src/components/panel-error-boundary.tsx
  • src/lib/web3/contract-service.ts
  • src/lib/web3/transaction-feedback.ts

Exact head: 9c967a74e10402b34b68d191fb2e7e450db2f52f (13 commits / 5 files / +570 -121).

Current-head acceptance notes

  • all six checked action methods preserve explicit transaction progress and now route their signed transaction through one helper that computes the local hash before sendTransaction;
  • a thrown sendTransaction call records pending(localHash) and raises PendingTransactionError(localHash), so an RPC response loss cannot invite a blind duplicate submission;
  • TRY_AGAIN_LATER remains the explicit retryable send response; ERROR does not emit pending; both PENDING and DUPLICATE wait for confirmation using waitForConfirmation(txHash) at all six milestone gates; non-error returns use the resolved txHash;
  • the centralized feedback mapping covers the contract error-code surface reviewed against issue [Frontend] Transaction state machine + error-code surfacing in the UI #44;
  • pending-with-hash stays status-check-only before any retry, preserving the no-double-submit boundary;
  • AppLayout keys the existing PanelErrorBoundary by React Router location identity, allowing route B to render after a route-A render fault without requiring a manual Retry first.

Validation boundary

Hosted Build and Test run 37506838167 completed action_required on a prior head; that historical run does not validate the current head. No current-head CI-green claim is made. The repository package scripts expose no maintained test runner for the latest one-file transaction-lifecycle repair, so no new test framework or broad verification matrix was introduced. Readback confirms exactly one helper and exactly six issue-facing helper call sites, with the prior direct send/pending blocks removed from those methods. No full-suite, hosted-CI, browser/device, or live-chain green claim is made here.

Claim and compensation

This PR continues my existing /claim #44 contribution. I request recognition of my authorship and claim, assignment where required, and payment for this work through the applicable GrantFox bounty process. Please confirm eligibility, the payable amount, and the payment timing. This request preserves the existing claim; it does not assert an award or settlement that has not been confirmed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Frontend] Transaction state machine + error-code surfacing in the UI

1 participant