[Feature] Build an offline-resilient transaction recovery system for interrupted submissions

[grantfox-oss]

Getting Started

1. Fork the repository: https://github.com/JointSave-org/Joint_Save
2. Clone your fork:

   git clone https://github.com/<your-username>/Joint_Save.git
   cd Joint_Save

3. Create a new branch:

   git checkout -b feat/transaction-recovery-system

---

Overview

If a user submits a transaction (deposit, withdraw, trigger_payout) and then closes the browser tab, loses internet connectivity, or their device sleeps before the app finishes polling for confirmation, there is currently no way to recover the outcome. The transaction may have actually succeeded on-chain, but the user has no client-side record of it and may assume it failed, risking a double-deposit or duplicate withdrawal attempt. This complements the optimistic-UI work already merged — that makes the UI feel faster, but doesn't yet handle the case where confirmation never arrives because the tab closed.

Requirements

Persisted Pending Transaction Log

• Before submitting any signed transaction, write a record to localStorage under a key like jointsave:pending-tx:<address>:

  { "hash": "...", "type": "deposit", "poolId": "...", "submittedAt": 1234567890, "amount": "100" }

• On app load (in web3-provider.tsx or a new TransactionRecoveryProvider), check for any pending transaction records for the connected wallet address
• For each pending record, query server.getTransaction(hash) to determine the actual outcome:
  • SUCCESS → remove from pending log, show a toast: "Your deposit from earlier completed successfully"
  • FAILED → remove from pending log, show a toast with the failure reason
  • NOT_FOUND after 5 minutes from submittedAt → treat as likely dropped, remove from log, inform the user it may need to be resubmitted

Duplicate Submission Guard

• Before allowing a new deposit/withdraw/payout submission on the same pool, check if there's already a pending record for that exact pool + action type within the last 2 minutes
• If so, show a confirmation dialog: "You have a recent pending [action] on this pool. Submit anyway?" rather than blocking outright (the user may have legitimately waited and confirmed it failed)

Acceptance Criteria

• Closing the tab mid-transaction and reopening the app shows the correct resolved outcome for that transaction
• Pending transaction records are cleaned up after resolution (no localStorage leak growing unbounded)
• Duplicate submission guard triggers correctly within the 2-minute window and not after
• Works correctly across deposit, withdraw, and trigger_payout action types
• No false positives — a normal single submission never triggers the duplicate warning

[Ebenezer199914]

i will like to work on this

[Sundriveauto]

Hi Team,

I am writing to submit my application to design and build our offline-resilient transaction recovery system. In decentralized networks and Web3 apps, unexpected drops in connectivity mid-submission often result in a terrible user experience—leaving users blind to whether their transaction was broadcast, partially processed, or dropped entirely.

I will implement a reliable, stateful transaction recovery pipeline that securely caches pending transactions locally, safely detects network restoration, and automatically reconciles submissions without risking duplicate executions.

[Menjay7]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. Thank you!

[primexk5]

gm, I'd like to take this on.

Plan: add a transaction recovery layer keyed to the connected wallet. Before submitting any signed tx (deposit/withdraw/trigger_payout), I'll write a pending record to localStorage under jointsave:pending-tx:<address>. On app load (a TransactionRecoveryProvider, or in web3-provider.tsx), I'll scan pending records for the connected address and resolve each via server.getTransaction(hash) — SUCCESS → clear + success toast, FAILED → clear + failure-reason toast, NOT_FOUND past 5 min from submittedAt → treat as dropped, clear, and prompt possible resubmit. Records are removed on resolution so the log can't grow unbounded. I'll add the duplicate-submission guard: a new submission on the same pool + action within 2 minutes surfaces a "submit anyway?" confirmation rather than hard-blocking, scoped so a normal single submission never triggers it.

I'll verify the tab-close-and-reopen flow resolves correctly across all three action types and that the 2-minute window is precise (no false positives). Comfortable with the Stellar/web3 client side. Can turn this around shortly.

[grantfox-oss]

🦊 GrantFox — @primexk5 has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #70)
2. Your PR will be reviewed by the JointSave-org maintainers

Good luck! Track your progress on GrantFox.