Go Wallet Toolbox v0.191.1 Fixes Lost Transaction Status Notifications

Developer Tools

In Brief

Go Wallet Toolbox has released version 0.191.1, correcting a failure that could leave applications without transaction-status notifications after a background task stopped partway through its work.

The wallet database could already record a transaction as mined while the corresponding notification was discarded. The release preserves those completed results and also adds administrator statistics for storage and connected services.

News Report

Go Wallet Toolbox v0.191.1 was published on October 21, 2026, at 13:33 UTC.

The Go library supplies components for BRC-100 wallets, including persistent storage, background monitoring and connections to blockchain services. Its transaction-status events allow other application components to respond when a transaction is broadcast or receives evidence of inclusion in a block.

The release includes two substantive contributions: a correction to partial-failure handling and new administrator statistics.

A Completed Update Could Lose Its Notification

During transaction-status synchronization, the toolbox looks for Merkle proofs showing that transactions have been included in blocks. As each proof is found, the corresponding database update is committed immediately.

The notifications for those updates were collected in memory for publication afterward.

If the run subsequently reached its time limit, was canceled or encountered another error, the previous implementation could return no results. Higher layers then discarded the notifications for transactions whose database updates had already succeeded.

That could make the loss permanent within the monitoring workflow. A transaction marked completed was no longer selected for the next proof-checking run, so its missing notification would not simply be regenerated on the next attempt.

The contribution describes a similar problem with broadcasting: successful batches could lose their notifications when another batch failed during the same task.

Preserving Results When a Task Partly Fails

Version 0.191.1 returns the status changes already committed together with the error. The monitoring tasks publish those results before reporting the failure.

An incomplete synchronization run still leaves the block eligible for another attempt, allowing unfinished work to be retried.

This means a task can legitimately report an error while also publishing valid transaction updates. Those updates represent work that succeeded before the failure.

The correction addresses notification handling during future runs. The reviewed changes do not include a replay mechanism for notifications lost before an upgrade.

Tests Cover Interrupted Work

One new regression test cancels a synchronization run while it is fetching the second transaction’s proof. It checks that the first transaction remains recorded as mined and is still returned among the results, alongside the cancellation error.

Additional tests check that proof-status notifications are published despite a synchronization error and that successful broadcast batches are forwarded when other batches fail.

The contributor reports passing the relevant storage and monitor tests and Go’s static-analysis checks.

Administrator Statistics Added

The release also adds storage-wide counters covering users, transactions, transaction statuses and other wallet records for the past 24 hours, seven days and thirty days, plus overall totals.

Service statistics record recent calls by service method and provider, including duration and outcome. The recent-call history retains up to 32 calls per method/provider combination and resides in memory, so it resets when the process restarts.

The storage server exposes the statistics through an authenticated administrator endpoint restricted to configured identity keys. The endpoint is absent when no administrator keys are configured. Applications exposing the underlying statistics method themselves must apply their own access controls.

The contributor describes these aggregate queries as suitable for occasional administrator use, since their cost grows with the database.

BSV TIMES Read

Wallet reliability depends on both recording a transaction’s state and communicating that state to the application using the wallet.

This release addresses the gap between those two responsibilities. A background task can complete useful work before encountering a failure, and the completed work still needs to reach its subscribers.

The accompanying statistics give operators more information about storage activity and service behavior. Together, the changes improve how wallet infrastructure reports what happened and how operators investigate problems.

Developer Context

Paweł Lewandowski, using the GitHub account pawellewandowski98, authored both the transaction-status correction and the administrator-statistics contribution.

His public GitHub profile describes him as a software engineer and lists 4chain studio as his organization.

Source Links

Posted on October 22, 2026 (UTC)