Context
Surfaced by CodeRabbit during review of #711. The behavior described here pre-dates that PR — #711 is a structural-only split of ManagedCoreAccount into ManagedCoreFundsAccount + ManagedCoreKeysAccount and explicitly does not change runtime behavior.
Problem
On ManagedCoreFundsAccount, only next_receive_address and next_change_address bump monitor_revision after extending the watched address pool. The following pool-mutating paths do not:
next_receive_addresses / next_change_addresses (batch helpers)next_address / next_address_with_info (non-Standard single-pool accounts)next_bls_operator_key / next_eddsa_platform_keynext_private_key / peek_next_path / mark_first_pool_index_used / next_pathmark_address_used
When any of these extend the monitored address set, mempool / bloom-filter consumers can keep watching the old set until some unrelated mutation later happens to bump the counter.
Suggested fix
Each helper that grows or otherwise mutates a pool should call bump_monitor_revision() (or equivalent) on the success path before returning. The existing next_receive_address / next_change_address increments are the reference pattern.
Files
key-wallet/src/managed_account/managed_core_funds_account.rs
Original review thread: #711 (review comment 3178371384)
Context
Surfaced by CodeRabbit during review of #711. The behavior described here pre-dates that PR — #711 is a structural-only split of
ManagedCoreAccountintoManagedCoreFundsAccount+ManagedCoreKeysAccountand explicitly does not change runtime behavior.Problem
On
ManagedCoreFundsAccount, onlynext_receive_addressandnext_change_addressbumpmonitor_revisionafter extending the watched address pool. The following pool-mutating paths do not:next_receive_addresses/next_change_addresses(batch helpers)next_address/next_address_with_info(non-Standard single-pool accounts)next_bls_operator_key/next_eddsa_platform_keynext_private_key/peek_next_path/mark_first_pool_index_used/next_pathmark_address_usedWhen any of these extend the monitored address set, mempool / bloom-filter consumers can keep watching the old set until some unrelated mutation later happens to bump the counter.
Suggested fix
Each helper that grows or otherwise mutates a pool should call
bump_monitor_revision()(or equivalent) on the success path before returning. The existingnext_receive_address/next_change_addressincrements are the reference pattern.Files
key-wallet/src/managed_account/managed_core_funds_account.rsOriginal review thread: #711 (review comment 3178371384)