feat: load real transaction history in demo app by j-kon · Pull Request #102 · bitcoindevkit/bdk-dart

j-kon · 2026-06-30T13:08:57Z

Summary

replace transaction history sample rows with active-wallet-backed data
map BDK wallet transactions into demo-app history rows
bind transaction repositories to both the logical wallet ID and live FFI wallet
clear stale transaction state when the loaded wallet is missing or changes
refresh mounted transaction history immediately after a successful broadcast
show distinct no-wallet states for transaction list and detail screens
add provider-chain regression coverage for mounting, wallet switching, replacement, clearing, stale loads, and broadcast refresh
keep widget tests lightweight by using fake transaction repositories without constructing real BDK wallets

Context

Continues the transaction presentation scaffold from #62 by wiring the list/detail flow to active wallet transaction data instead of sample rows.

The production transaction repository uses the BDK Dart API to read wallet transactions. Transaction state remains auto-disposed and keyed by logical wallet ID, while an active wallet binding ensures each provider only reads from the matching FFI wallet.

Wallet replacement refreshes existing rows, wallet clearing removes stale rows, delayed results cannot cross wallet boundaries, and successful broadcasts invalidate the active wallet transaction controller.

Verification

dart format --output=none --set-exit-if-changed lib test example bdk_demo/lib bdk_demo/test
dart analyze --fatal-infos --fatal-warnings lib test example
dart test
flutter analyze inside bdk_demo
flutter test --no-pub test inside bdk_demo

Validation passed:

root Dart tests: 22 passed, 5 environment-gated integration tests skipped
bdk_demo Flutter tests: 201 passed
no analyzer or formatter issues

…tate and native resource disposal

…from widget tests

…_page_test.dart

Shamsudeen12 · 2026-07-14T00:04:14Z

Hi @j-kon, nice work here

I noticed something. The transactionsControllerProvider isn't auto-disposed, so it outlives the TransactionsListPage and persists the data for the previous session. It gates on hasActiveWalletProvider, which is a boolean and switching from wallet A to wallet B through the Active Wallets screen (active_wallets_page.dart → activeWalletProvider.notifier.set(...)) leaves that provider at true, so the controller's build() never re-runs and the list keeps rendering wallet A's transactions under wallet B.

Steps to reproduce: load wallet A → open Transactions → Load Transaction History → switch to wallet B → reopen Transactions. It still shows wallet A's transactions; tapping one resolves against B's repository and 404s as "Transaction not found."

The sibling providers already handle this by keying off wallet identity, blockchain_providers.dart resets when activeWalletRecordProvider.id changes. Might be worth having the controller watch an activeWalletId (or ref.listen the record and reset) instead of a bool. Happy to be corrected if in-place switching isn't a supported flow.

j-kon · 2026-07-14T01:20:43Z

Thanks for the detailed. You were right that the transaction state was scoped only to wallet availability rather than the logical active wallet.

I updated the transaction list and detail flow to use the active wallet record ID. Switching from wallet A to wallet B now clears the previous wallet’s transaction state, and stale asynchronous results are ignored if the active wallet changes before loading completes.

I also added coverage for wallet switching so transaction list and detail data cannot leak between active wallets.

…transaction-history

Shamsudeen12 · 2026-07-14T12:58:01Z

Thanks @j-kon
Everything looks good from my end 🙌🏾

Johnosezele

Every time I leave the wallet/Home flow and navigate back to Transaction History, I land on "Transaction history not loaded yet" and have to tap Load Transaction History again, even right after a successful sync with txs already known to the wallet (Home shows the balance).

Likely related to transactionsControllerProvider being NotifierProvider.autoDispose.family keyed by wallet ID: leaving the page disposes the controller, so remount always returns TransactionsState.idle().

Please either:

keep loaded history for the active wallet across navigations (drop autoDispose, or cache last success by wallet ID), or
auto-load on page open when an active wallet is present,

and add widget coverage that pumps the list page, navigates away, returns and still shows (or auto-reloads) the previously loaded rows without an extra tap.

Johnosezele

After an incoming tx confirms, Home correctly updates (Balance + Trusted spendable reflect the synced wallet), but Transaction History can still show the earlier pending row until I leave, come back, and tap Reload Transaction History.

So for a while Home and History disagree: spendable says confirmed funds are available, history still says "Awaiting confirmation."

Root cause looks like split data paths:

Home reads wallet.balance() via balanceSnapshotProvider on every successful sync
History only refreshes on explicit Load/Reload of transactionsControllerProvider (and with autoDispose it also drops to idle when leaving the route)

Please invalidate or auto-reload transaction history for the active wallet when sync completes (same moment balance is applied), so pending, confirmed cannot lag behind Home.
Widget coverage: load history while pending, then, apply post-sync wallet, and assert list shows confirmed without a manual reload.

… completion

j-kon · 2026-07-22T06:19:26Z

Thanks @Johnosezele for the detailed review! I've updated PR #102 in commits e9b32f0 and 1958c9d:

Auto-load on Navigation: Added microtask auto-loading in TransactionsController.build(). Navigating to TransactionsListPage now automatically loads transaction history without showing an un-loaded state or requiring a manual button tap.
Auto-reload on Wallet Sync & Post-Broadcast: TransactionsController now listens to activeWalletProvider and syncStatusProvider (SyncStatus.synced), and send_page.dart triggers background transaction reloads upon broadcast success. As soon as a sync completes or a transaction confirms on-chain, transaction history auto-refreshes in the background without UI flicker or manual reloading.
Widget Coverage: Added widget tests covering automatic initial load, navigation away and back, auto-reload on wallet sync (pending -> confirmed transition), and wallet switching.

Johnosezele · 2026-08-04T13:53:56Z

          .read(balanceSnapshotProvider.notifier)
          .applyFromWallet(wallet, record.id);
-      ref
-          .read(transactionsControllerProvider(record.id).notifier)


Quick check on dropping this.
History refresh now relies on activeWalletProvider changing via replaceWallet...after broadcast we only applyFromWallet on the same wallet instance, so does the outgoing tx show in transaction history right away, or only after the next sync?

Fixed in 0986214. Successful broadcasts now invalidate the wallet-scoped transaction controller, so an already-mounted history reloads immediately. Added widget coverage for this flow.

Johnosezele

I've left some questions and nits here

Johnosezele · 2026-08-04T22:34:01Z

+        FilledButton,
+        'Load Transaction History',
+      );
+      expect(tester.widget<FilledButton>(buttonFinder).onPressed, isNull);


nit: find.widgetWithText(FilledButton, …) breaks on newer Flutter, try to assert via the label + ButtonStyleButton ancestor...

Fixed in 0986214. The test now finds the label and asserts through its ButtonStyleButton ancestor, avoiding the newer-Flutter FilledButton finder issue.

Johnosezele · 2026-08-04T22:41:25Z

  ActiveWalletNotifier.new,
 );

+final hasActiveWalletProvider = Provider<bool>((ref) {


hasActiveWalletProvider isn’t used anywhere, can we drop it?

Fixed in 0986214. Removed the unused hasActiveWalletProvider; transaction views now use the wallet-bound availability provider.

Johnosezele · 2026-08-04T22:53:42Z

                title: 'Transaction not found',
                message:
-                    'No placeholder transaction was found for this txid.\n\n$txid',
+                    'No wallet transaction was found for this txid.\n\n$txid',


on detail, if there’s no active wallet the lookup comes back null, and we show the same “Transaction not found” card as for a missing txid... that makes it look like the tx is gone, when the issue is there’s no wallet loaded.

Fixed in 0986214. The detail page now shows a dedicated no-active-wallet state before starting the transaction lookup, with widget coverage that keeps it distinct from a missing txid.

Johnosezele · 2026-08-04T23:04:26Z

+        mappedPosition = UnconfirmedTransactionPosition(
+          timestamp: position.timestamp,


timestamp is stored on UnconfirmedTransactionPosition but the mapper never reads it, keep for later UI or drop?

Fixed in 0986214. Dropped the unused timestamp from UnconfirmedTransactionPosition and stopped carrying it through the mapper.

Johnosezele · 2026-08-04T23:40:10Z

+    final controllerProvider = transactionsControllerProvider(activeWalletId);
+    final state = ref.watch(controllerProvider);
    final isLoading = state.status == TransactionsLoadState.loading;
+    final canLoad = activeWalletId != null && !isLoading;


canLoad only checks activeWalletId != null, not that an FFI wallet is loaded. A record without a wallet can still enable load and show empty success. Should we gate on activeWalletProvider or both?

Fixed in 0986214. Loading now requires a matching logical wallet ID and live FFI wallet binding. Record-only and cleared-wallet states disable loading, clear stale rows, and have focused regression coverage.

j-kon · 2026-08-06T02:43:06Z

Thanks for the detailed review, John. I’ve gone through the six open threads and I understand the concerns.

The main issue is that the transaction history refresh path is still not fully consistent after broadcast, and there are also a few state and cleanup problems around wallet availability, empty states, and the tests.

I haven’t fixed these yet. I’m going to address them one by one, add focused regression coverage, and avoid pushing another broad update until I’ve verified the behavior locally.

I’ll reply to each thread with the exact change and test once it is done. Thanks for taking the time to review this carefully.

j-kon · 2026-08-10T07:19:57Z

@Johnosezele All six open review points are addressed in 0986214, with direct thread replies and regression coverage. Formatting and analyzers pass; root tests are 22 passed with 5 integration skips, and the demo suite is 201 passed. Ready for re-review when convenient.

j-kon added 7 commits June 30, 2026 13:42

docs: plan real transaction history

71d07ad

refactor: rename transaction history model

3ae8a7d

feat: map wallet transactions for history

45141ad

feat: load real wallet transaction history

8b46b1e

chore: clean up PR 102, delete docs, fix UTC time, handle no wallet s…

7cad683

…tate and native resource disposal

refactor: extract hasActiveWalletProvider and remove real BDK wallet …

db69a39

…from widget tests

test: rename helper parameter to hasActiveWallet in transactions_list…

af67b6a

…_page_test.dart

j-kon marked this pull request as ready for review June 30, 2026 14:35

Scope transactions controller and details to active logical wallet ID

184bbfc

j-kon added 2 commits July 14, 2026 12:48

Merge remote-tracking branch 'upstream/main' into feat/bdk-demo-real-…

c1cb1bf

…transaction-history

fix(demo): clean up transaction history resources

e4c458c

Shamsudeen12 approved these changes Jul 14, 2026

View reviewed changes

Johnosezele requested changes Jul 16, 2026

View reviewed changes

Comment thread bdk_demo/lib/features/transactions/transactions_controller.dart Outdated

fix(demo): scope transaction state by wallet ID

969da23

Johnosezele mentioned this pull request Jul 20, 2026

bdk_demo: Home shows pending funds as balance; add pending tx summary under Send/Receive #119

Open

4 tasks

Johnosezele requested changes Jul 20, 2026

View reviewed changes

j-kon added 2 commits July 21, 2026 16:12

feat: automatically load and refresh transaction history

e9b32f0

feat: auto-reload transactions in background after broadcast and sync…

1958c9d

… completion

j-kon added 3 commits July 22, 2026 07:33

fix: stabilize transaction history refresh lifecycle

54114a7

ci: trigger fresh build on all platforms

aa1fe5a

fix: queue pending transaction refreshes and resolve analyzer warning

270a415

Johnosezele reviewed Aug 4, 2026

View reviewed changes

Johnosezele requested changes Aug 4, 2026

View reviewed changes

fix(demo): address transaction history review feedback

0986214

j-kon mentioned this pull request Aug 10, 2026

bug(demo): broadcast transactions through the selected network endpoint #123

Open

		mappedPosition = UnconfirmedTransactionPosition(
		timestamp: position.timestamp,

Uh oh!

Conversation

j-kon commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Context

Verification

Uh oh!

Shamsudeen12 commented Jul 14, 2026

Uh oh!

j-kon commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Shamsudeen12 commented Jul 14, 2026

Uh oh!

Uh oh!

Johnosezele left a comment

Choose a reason for hiding this comment

Uh oh!

Johnosezele left a comment

Choose a reason for hiding this comment

Uh oh!

j-kon commented Jul 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Johnosezele left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

j-kon commented Aug 6, 2026

Uh oh!

j-kon commented Aug 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

j-kon commented Jun 30, 2026 •

edited

Loading

j-kon commented Jul 14, 2026 •

edited

Loading