Skip to content

fix: trust_peer_addr flaky test; atomic fetch_update -> try_update - #1205

Merged
reardencode merged 2 commits into
reardencode:masterfrom
phlip9:phlip9/minor-fixes
Oct 25, 2026
Merged

reardencode merged 2 commits into
reardencode:masterfrom
phlip9:phlip9/minor-fixes

Conversation

@phlip9

@phlip9 phlip9 commented Oct 25, 2026 •

Copy link
Copy Markdown
Contributor

Two small fixes:

  • atomics: fetch_update → try_update:

    • rustc 1.99 deprecates AtomicU64::fetch_update (and others) and so we get warnings when building with a newer compiler
    • try_update is stable since 1.95.0, which is also our MSRV. fetch_update is now just an alias for try_update
  • fix flaky cli::trust_peer_addr test, which races on RBITCOIN_P2P_MAX_INBOUND

    • trust_peer_addr asserts max_inbound == DEFAULT_MAX_INBOUND, but operator_config_from_args absorbs RBITCOIN_P2P_MAX_INBOUND. cli_omit_preserves_advanced_env sets that env to 91 under OPERATOR_ENV_TEST_LOCK for a whole --smoke run, and trust_peer_addr did not take the lock:
---- cli::trust_peer_addr stdout ----
error: --trust-peer requires a value

thread 'cli::trust_peer_addr' panicked at crates/rbitcoin-node/tests/cli.rs:735:5:
assertion `left == right` failed
  left: 91
 right: 125

trust_peer_addr now takes the lock, like the other env-reading tests.

There's a more systematic fix for this issue (don't set/remove envs in tests), but I'll post that in a followup PR. These are just the basic fixes.

Rust 1.99 deprecates the atomic fetch_update as a rename of try_update.
try_update is stable since 1.95.0, our MSRV, and fetch_update only
forwards to it, so behavior does not change.
trust_peer_addr asserts the parsed default max_inbound is
DEFAULT_MAX_INBOUND (125), but parsing absorbs RBITCOIN_P2P_MAX_INBOUND.
cli_omit_preserves_advanced_env sets that env to 91 under
OPERATOR_ENV_TEST_LOCK for a whole --smoke run, and trust_peer_addr did
not take the lock. When the two overlap, `plain` reads 91.

On master with rustc 1.95, the node suite failed 8 of 10 runs and the
two tests alone failed 20 of 20. With the lock, 10 of 10 and 20 of 20
pass.
@phlip9 phlip9 changed the title fix: trust_peer_addr flakey test; atomic fetch_update -> try_update fix: trust_peer_addr flaky test; atomic fetch_update -> try_update Oct 25, 2026

@rearden-grok rearden-grok Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

APPROVE. 0 bugs, 0 suggestions, 0 nits.

No review comments are on the pull request, including from coreyphillips.

Atomic*::try_update is the same operation as fetch_update: it retries the compare-and-swap, returns Ok(previous), and takes the same success and failure orderings. It has been stable since Rust 1.95.0, which is this tree's minimum compiler, and fetch_update only forwards to it from the 1.99 deprecation. Every fetch_update in the tree is renamed, and the orderings at those sites stay legal (Relaxed, Acquire, Release, AcqRel, SeqCst). Callers that use the Ok value (note_batch_depth_send, note_send_written, note_spend_annotate_pending) still see the previous word.

trust_peer_addr now holds OPERATOR_ENV_TEST_LOCK for the whole parse, which is the mutex cli_omit_preserves_advanced_env already holds while RBITCOIN_P2P_MAX_INBOUND=91 is set. That assertion is the only check of the default inbound cap in the cli test binary. --trust-peer still forces max_inbound to 0 after the env is absorbed, so the sibling tests in that binary do not depend on the default. Nothing operator-visible changes, so there is no changelog.d note.

@reardencode
reardencode merged commit d1b71be into reardencode:master Oct 25, 2026
18 checks passed
@phlip9
phlip9 deleted the phlip9/minor-fixes branch October 25, 2026 16:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants