refactor: consolidate exp backoff config into pluto_core::expbackoff#505
Open
varex83agent wants to merge 1 commit into
Open
refactor: consolidate exp backoff config into pluto_core::expbackoff#505varex83agent wants to merge 1 commit into
varex83agent wants to merge 1 commit into
Conversation
Charon defines a single app/expbackoff package (FastConfig: 100ms/5s, DefaultConfig: 1s/120s, x1.6, 0.2 jitter). The equivalent backon ExponentialBuilder setup was copy-pasted across scheduler.rs, sse/mod.rs and bootnode.rs. Extract a shared pluto_core::expbackoff module exposing fast() and default() builders and migrate the three call sites, closing the TODOs at scheduler.rs:722 and sse/mod.rs:506. While consolidating, fix a latent divergence in bootnode.rs: its query_relay_addresses builder omitted without_max_times(), so it silently capped at backon's default of 3 retries. Go's queryRelayAddrs is documented "It retries until the context is cancelled"; routing it through expbackoff::fast() restores that behavior. dial.rs is left untouched: it is a hand-rolled Stream (not a backon builder) that already retries forever and reproduces Go's exact jitter math. cli/relay.rs and app/retry.rs use deliberately distinct configs and are out of scope. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Charon has a single
app/expbackoffpackage (FastConfig: 100ms/5s,DefaultConfig: 1s/120s, both ×1.6 with 0.2 jitter). In Pluto the equivalentbackon::ExponentialBuildersetup was copy-pasted acrosscore/scheduler.rs,app/sse/mod.rs, andp2p/bootnode.rs.This PR extracts a shared
pluto_core::expbackoffmodule exposingfast()anddefault()builders and migrates the three call sites, closing the TODOs atscheduler.rs:722andsse/mod.rs:506.Latent bug fixed
While consolidating,
bootnode.rs::query_relay_addresseswas found to omit.without_max_times()on itsbackon.retry()call, so it silently capped at backon's default of 3 retries. Go'squeryRelayAddrsis documented "It retries until the context is cancelled" (and its caller usesWithFastConfig()in afor ctx.Err() == nilloop). Routing it throughexpbackoff::fast()(which includeswithout_max_times) restores the Go-equivalent behavior — it now retries until the cancel token fires.Notes
backon::with_jitter()is an approximation of Go's ±20% multiplicative jitter, documented in the new module. Every migrated site already used.with_jitter(), so there is no behavioral change beyond the bootnode retry-cap fix.sse::reconnect_backoff()is kept local — it'sDEFAULT_RETRY-based, not a Go Fast/Default config.Verification
cargo +nightly fmt --all --check✅cargo clippy -p pluto-core -p pluto-app -p pluto-p2p --all-targets --all-features -- -D warnings✅cargo test -p pluto-core -p pluto-app -p pluto-p2p --all-features✅ (57 / 542 / 96 passed, 0 failed)🤖 Generated with Claude Code