fix(replication): tolerate new KClosestPeersChanged fields from saorsa-core - #201
Merged
Merged
Conversation
…a-core saorsa-core `ea766ea` (PR #136) added `added` and `removed` fields to `DhtNetworkEvent::KClosestPeersChanged`. The enum is not `#[non_exhaustive]`, so adding fields to the struct variant is source-breaking for external matchers, and this is ant-node's only one — `cargo check` fails with E0027 against saorsa-core `main`. That went unnoticed because ant-node pins saorsa-core 0.26.4 from crates.io plus a `[patch.crates-io]` override on rev a4faf6f, which is #149's branch head and predates #136. ant-node has never compiled against a saorsa-core carrying #136; the rc-2026.8.2 cut is what first forced the two together. Match with `..` so the pattern is tolerant of the new fields. Behaviour is unchanged: the fields are ignored and `old`/`new` are used exactly as before. `..` is valid whether or not the extra fields are present, so this compiles against both the current pins and the rc lineage. Deliberately does not adopt `added`/`removed`. #136 added them so consumers can track K-closest entrants directly instead of recomputing them, which is plausibly what this call site should do — but that is a design change for the replication owners, not something to decide while unblocking a release cut. Co-Authored-By: Claude Opus 5 (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
1 participant
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.
Linear issue
V2-959 — https://linear.app/autonominetwork/issue/V2-959/ant-node-adapt-to-dhtnetworkeventkclosestpeerschanged-gaining
Blocks the 2026-08-11 release train cut (V2-906).
Risk tier
Compatibility
Semver impact
Test evidence
cargo check --all-targets --all-featuresagainst currentmainpins (saorsa-core 0.26.4 + the[patch.crates-io]reva4faf6f) — passes...is valid whether or not the extra fields exist, so this does not depend on which saorsa-core is resolved.cargo check --all-targets --all-featuresagainst the rc-2026.8.2 saorsa-core lineage (0.27.0-rc.1, which contains feat(payment): accept flexible single-node proof bundles #136) — passes. Without this change the same check fails witherror[E0027]: pattern does not mention fields added, removedatsrc/replication/mod.rs:3009.src/replication/mod.rs:3009is ant-node's only match on this variant, confirmed by grep acrosssrc/.New dependency
none
ADR
n/a — no decision changes. The event shape is saorsa-core's; this only makes ant-node's pattern tolerant of it.
Mitigation / rollback
Single-line revert. Reverting restores the E0027 build failure against saorsa-core ≥ 0.27.0, so it should only be reverted alongside pinning saorsa-core back below #136.
Why this was not caught earlier
ant-node
mainpinssaorsa-core 0.26.4from crates.io plus a[patch.crates-io]override on reva4faf6f— #149's branch head, which predates #136. ant-node has therefore never compiled against a saorsa-core containing #136, and the break stayed latent until the rc cut forced bothmainbranches together.Separately: saorsa-core #136 declared its semver impact as
feature; adding fields to a non-#[non_exhaustive]enum variant isbreaking. The train's saorsa-core version is unaffected (#149 independently declared breaking, so it was already going to 0.27.0), but the declaration was wrong and the PR body's Compatibility section did not mention the enum, which is why manifest verification passed it.Not in scope
Adopting
added/removed. #136 added them so consumers can track K-closest entrants directly rather than recomputing them fromold/new, which is plausibly what this call site should do. That is a design change for the replication owners and is tracked separately rather than decided while unblocking a cut.