[GoodBounty]: Finalize MBPBridge refactor of tx history #270

Summary

Pick up the existing AI-generated PR for MPB bridge transaction history reliability, run it locally, validate the full bridge flow, fix implementation gaps, clean up AI-written code, and prepare the PR for human review.

• Issue: [Bug]: MPB Bridge Transaction History does not load reliably #268
• PR: Refactor MP bridge history to chunked per-chain log sync #269
• Branch: copilot/fix-mpb-bridge-transaction-history
• Contributor role reference: https://docs.gooddollar.org/for-developers/contributing/open-source-contributors/contributor-role

Contributor task

• Claim the bounty with an ETA.
• Check out PR Refactor MP bridge history to chunked per-chain log sync #269 and run it locally.
• Compare the implementation against issue [Bug]: MPB Bridge Transaction History does not load reliably #268, the PR description, and repository patterns.
• Validate that the bridge history flow works against real or approved test RPCs.
• Fix concrete bugs in behavior, state handling, tests, typing, performance, or code quality. (specifically related to the transaction history. any other bugs in the flow should be raised as comment/async during testing/finalizig)
• Review code quality and simplify structure where the current AI-generated implementation is either too monolithic or over-split into low-value helpers.
• (not done yet): Add narrow bridge-specific curated RPC list support for MPB history reads, without restructuring the existing sdk-v2 provider architecture.
• Clean up unnecessary AI artifacts, comments, noisy logs, and unrelated changes.
• Provide a demo video showing the full flow working end-to-end.
• Leave a handoff comment with what changed, what was tested, evidence links, and remaining risks.

Scope checks

• The PR solves issue [Bug]: MPB Bridge Transaction History does not load reliably #268 requirements.
• The implementation follows the issue plan or explains any deviation.
• Existing SDK and design package boundaries are respected.
• Cached transactions render immediately on warm load.
• Empty cache triggers a 30-day backfill without any eth_getLogs request over 500 blocks.
• Non-empty cache fetches only from each chain cursor forward.
• Per-chain RPC failures do not block successful chains from rendering and updating cache.
• Loading, refreshing, empty, and partial-error states are distinct in the UI.
• A completed bridge action visibly triggers history refresh.
• Manual refresh works without remounting the hook.
• Pending vs completed bridge rows still merge correctly across BridgeRequest and ExecutedTransfer.
• MPB history can use a curated bridge-specific RPC list, with fallback to the existing app-level readOnlyUrls.
• The curated RPC list is scoped to MPB bridge history reads and does not force a broad sdk-v2 provider architecture rewrite.
• Hooks/components are reviewed for responsibility boundaries: avoid one hook/component handling too much, but also avoid extracting one-line helpers that are only used once or twice and do not reduce complexity.
• Spending approval behavior is validated and fixed if stale allowance/approval state can cause skipped approval or stuck bridge execution.
• Desktop and mobile layouts are usable.
• PR description links the source issue and includes test evidence.
• The PR includes a demo video of the full flow.

Initial review notes

The PR appears to implement the intended direction:

• Replaces useLogs with direct provider.getLogs calls in packages/sdk-v2/src/sdk/mpbridge/hooks/useMPBBridgeHistory.ts.
• Adds chunk generation and cache merge helpers in packages/sdk-v2/src/sdk/mpbridge/hooks/useMPBBridgeHistory.helpers.ts.
• Adds helper tests in packages/sdk-v2/src/sdk/mpbridge/hooks/useMPBBridgeHistory.helpers.test.ts.
• Adds UI refresh/error state in packages/good-design/src/apps/bridge/mpbridge/TransactionHistory.tsx.
• Calls refreshHistory() after bridge success in packages/good-design/src/apps/bridge/mpbridge/feature/useMPBBridgeViewController.ts.

Known review risks to validate:

• The 30-day backfill may produce many getLogs calls across four chains and two event types; validate runtime, RPC rate limits, and user-facing loading behavior.
• The current implementation uses providers from the global usedapp readOnlyUrls; it does not add bridge-specific curated RPC support. (Missing and should add: support for rpcList for the bridge-flow)
• The PR includes .gitignore changes for local agent artifacts; remove or justify if unrelated.
• Spending approval behavior was flagged during review: after a previous per-transaction approval is consumed, the next bridge should re-check allowance and request approval when needed.

Additional implementation requirements

Code quality review

Review the AI-generated implementation for structure before requesting human review. The goal is simple, maintainable code:

• Do not leave one big hook or component responsible for unrelated concerns such as RPC fetching, cache persistence, event matching, UI state shaping, and display rendering.
• Do not overcorrect by moving trivial one-line expressions into helpers that are only used once or twice and do not clarify the code.
• Prefer extracting helpers only when they remove real complexity, reduce meaningful duplication, or create a unit that can be tested independently.
• Keep comments focused on non-obvious behavior; overly commenting is prefered

Bridge-specific curated RPC list

Add support for a curated RPC list used specifically by MPB bridge history reads. Keep this narrowly scoped.

Suggested simple approach:

• Add an optional prop near the high-level bridge entry point, likely MPBBridgeController, for example bridgeReadOnlyUrls?: Partial<Record<number, string>>.
• Pass that value through the MPB bridge feature/view hooks only as far as needed by transaction history.
• Update useMPBBridgeHistory to accept an optional RPC override map, for example useMPBBridgeHistory({ readOnlyUrls }).
• When an override URL exists for a chain, create the read-only provider for that chain from the override and use it for getLogs; otherwise keep the existing provider from app-level usedapp readOnlyUrls.
• Keep the change single-purpose: do not redesign Web3Provider, useReadOnlyProvider, or the wider sdk-v2 provider system unless there is no smaller working option.

The implementation should be deterministic enough for validation: the demo video and handoff notes must state exactly which RPC URLs were used for Fuse, Celo, Ethereum mainnet, and XDC.

Required commands

Run the relevant commands and include exact results in the PR handoff comment:

yarn
yarn lint
yarn workspace @gooddollar/web3sdk-v2 test packages/sdk-v2/src/sdk/mpbridge/hooks/useMPBBridgeHistory.helpers.test.ts --runInBand
yarn workspace @gooddollar/web3sdk-v2 build
yarn workspace @gooddollar/good-design build

If a command cannot be run, document the exact command, failure output, environment, and whether the failure is pre-existing or introduced by PR #269.

Manual verification

Validate the MPB bridge screen with a connected wallet and supported source/target route.

• First open with empty cache performs a 30-day backfill and eventually renders history or a correct empty state.
• Second open with populated cache shows cached rows immediately (you need to do at least one transaction, funds can be shared once you are at this stage, ping @L03TJ3 ).
• Background refresh shows a visible refreshing state while keeping cached rows visible.
• Manual Refresh fetches from cached cursors forward.
• A new bridge transaction triggers history refresh after success.
• The new transaction appears as pending and later resolves to completed when the target event is available.
• One failing RPC/network does not prevent other chains from updating.
• No eth_getLogs request exceeds 500 blocks.
  -- Note: I have had a test where it was even denied saying 'cannot be more then 50 blocks'. I dont remember or saw clearly what RPC or what chain, but this is where the support for rpcList comes from. Should mainly rely for this flow on more well-known public rpcs per chain)
• Curated bridge RPC URLs are used when provided, and the existing app-level readOnlyUrls remain the fallback.
• Approval is requested when current allowance is insufficient for the transaction amount.
• The flow is usable on desktop and mobile viewport sizes.

Demo video requirement

Attach or link a demo video in the PR handoff comment. The video must show:
A single flow from doing a bridge > confirming the bridge and showing that the transaction history accurately updates.

Handoff comment

Please use the hand-off comment template found here: https://github.com/GoodDollar/GoodWidget/blob/main/docs/contributor-bounty-template.md#handoff-comment

Out of scope

• Do not redesign the bridge UI beyond what is needed for clear loading, refresh, error, and history states.
• Do not change bridge contract behavior.
• Do not broaden the task to unrelated bridge providers or unrelated SDK packages.