Multisig proposal polling

[dewabisma]

Summary

• Add fetch proposals to polling in multisig account
• Pull to refresh home page also fetch proposals in multisig account

---

Note

Low Risk
Read-only provider invalidation/refetch scoped to the active multisig account; no changes to signing, auth, or transaction submission.

Overview
Multisig proposal data now stays in sync with the same refresh paths that already update balances and transaction history when a multisig account is selected.

polling_refresh_scope gains multisigAccountFromActive, invalidateActiveMultisigProposals, and refreshActiveMultisigProposals (invalidates open/past proposal providers and current block, then awaits reload). Background global history polls invalidate proposals; manual global refresh, home pull-to-refresh, silent refresh via the history polling manager, and account switch all hook into these helpers (pull-to-refresh and manual global refresh wait for fresh proposal data).

Unit tests cover multisigAccountFromActive for multisig vs regular/entrusted/null active accounts.

^{Reviewed by Cursor Bugbot for commit f4f175f. Configure here.}

[n13]

Review of PR #513

The PR's overall approach is right — it does not add a new polling timer. It hooks multisig proposal invalidation into the four existing refresh paths (background poll, manual refresh, silent refresh on app-resume, account switch) and reuses the existing invalidateMultisigProposals helper from multisig_providers.dart. That's the DRY-friendly design. However, there are three real problems, one of them a crash.

1. Critical: ref as Ref in home_screen.dart will crash at runtime

await refreshActiveMultisigProposals(ref as Ref);

The repo is on flutter_riverpod 3.3.1. In Riverpod 3, WidgetRef and Ref are unrelated sealed classes — ConsumerStatefulElement implements WidgetRef only:

base class ConsumerStatefulElement extends StatefulElement
    implements WidgetRef {

So this cast throws TypeError every time, and since it runs unconditionally (before the multisig null-check inside the helper), pull-to-refresh on home breaks for all accounts, not just multisig ones. This was clearly never run on a device.

2. The duplication you asked about: the same refresh is wired twice, once into dead code

GlobalHistoryPollingService.triggerManualRefresh() gets await refreshActiveMultisigProposals(_ref) — but that method is only reachable via HistoryPollingManager.triggerManualRefresh(), which is called from nowhere (its own comment even says // This is not called from anywhere!). The real pull-to-refresh path is _HomeScreenState._refresh(), which got its own (broken) copy.

This perpetuates a pre-existing duplication: _refresh() in the home screen already reimplements most of triggerManualRefresh() (balance invalidation + loadingRefresh on the active account's pagination). The clean fix that solves both #1 and #2 at once: have _refresh() delegate to ref.read(globalHistoryPollingServiceProvider).triggerManualRefresh() — that runs with a real Ref, already awaits the proposal refresh after this PR, and removes the duplicated refresh logic instead of adding a third copy.

3. Minor: the two new helpers duplicate each other

refreshActiveMultisigProposals repeats invalidateActiveMultisigProposals's body (active-account lookup, null guard, invalidate) instead of building on it. Trivially restructured, e.g. have the invalidate helper return the MultisigAccount? and have refresh call it.

What's fine

• Reusing invalidateMultisigProposals rather than re-invalidating providers inline (notably, the existing confirm sheets like multisig_approve_confirm_sheet.dart invalidate inline and even miss multisigPastProposalsProvider — pre-existing, not this PR).
• No overlap with the existing multisig_*_polling_service.dart files — those track pending submitted extrinsics, a different concern; this PR covers external changes from other signers.
• Invalidate-only on background/silent paths vs. awaited refresh on user-initiated paths is the correct split, and matches how balances are handled.
• multisigAccountFromActive doesn't duplicate anything — existing code only had inline is MultisigDisplayAccount checks.

Verdict: architecture is sound and non-duplicative in intent, but it shouldn't merge as-is — the pull-to-refresh cast is a guaranteed crash, and the fix for it (delegating _refresh to triggerManualRefresh) also removes the one genuine duplication the PR introduces. Per your rules I haven't commented on GitHub; let me know if you want me to post this review on the PR.

[n13]

Review (agent-assisted, diffed against beast/cancel-proposal-flow)

Verdict: GTG — small, focused diff; three minor, non-blocking notes.

Minor

1. Manual refresh skips reconciliation on proposal-refresh failure — in GlobalHistoryPollingService.triggerManualRefresh, await refreshActiveMultisigProposals(_ref) runs before reconcilePendingTransactions(). If any proposal/block provider future fails, the method throws and reconciliation never runs for that refresh. The home screen catches the error, but consider try/catching the proposal refresh (or reordering) so reconciliation still happens.

2. Silent catch in timezone fallback — local_notifications_service.dart has a last-resort catch (_) {} with no logging when even the UTC fallback fails. Per repo convention (no silent failures), this should at least debugPrint/telemetry the error. Also, the message 'Failed to set device timezone "$e"' interpolates the exception where the timezone identifier is implied — minor wording nit.

3. Transient duplicate proposal rows possible — the background poll now invalidates open proposals (invalidateActiveMultisigProposals) independently of pending-event cleanup, so a just-indexed proposal can briefly render alongside its still-pending "Proposing…" row in the Open Proposals section until reconciliation removes the pending event. Cosmetic and self-healing, but worth knowing.

Checked and fine

• multisigAccountFromActive helper + unit tests cover multisig/regular/entrusted/null cases.
• Pull-to-refresh, manual global refresh, silent refresh, and account switch all consistently route through the new polling_refresh_scope helpers — good DRY consolidation (also removes the dead triggerManualRefresh in HistoryPollingManager).
• Reordering polling-service registration before notification init in AppInitializer makes listener attachment robust to notification init failures.