[4/n] [installinator] split fetching and progress reporting traits #8038
Conversation
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
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1 [skip ci]
jgallagher
approved these changes
Apr 24, 2025
installinator/src/reporter.rs
Outdated
| report: EventReport, | ||
| ) -> Result<SendReportStatus, ClientError> { | ||
| let log = self.log.new(slog::o!("peer" => peer.to_string())); | ||
| // For each peer, report it to the network. |
There was a problem hiding this comment.
Tiny nit - not sure this comment applies anymore? ("For each" sounds to me like we'll be looping over multiple peers, but that happens external to us now.)
Created using spr 1.3.6-beta.1 [skip ci]
Created using spr 1.3.6-beta.1
sunshowers
changed the base branch from
sunshowers/spr/main.4n-installinator-split-fetching-and-progress-reporting-traits
to
main
sunshowers
deleted the
sunshowers/spr/4n-installinator-split-fetching-and-progress-reporting-traits
branch
sunshowers
added a commit
that referenced
this pull request
Apr 26, 2025
There's been a long-standing issue with the installinator where reports to wicketd get delayed quite substantially. That happens because we use one task to send reports out to every peer, blocking until all of those peers come back. I'd assumed in the past that if installinator reached out to an unreachable peer, it would receive a TCP connection refused message, but that isn't the case -- instead, it times out. This causes reports to only be sent out roughly every 15 seconds which isn't ideal. To fix this issue, spin up separate report tasks for each peer. Introduce separate tasks for: * discovery (make this a persistent task that publishes updates to a watch channel) * peer reconciliation (new peers have new report tasks spun up, while removed peers' report tasks are cancelled) * reporting (each peer now has its own report loop) Also simulate some kinds of network flakiness in our property-based tests. I did a mupdate on dublin and saw that installinator reports started coming through every 2 seconds rather than every 15 or so, as expected. Depends on: - #8035 - #8036 - #8037 - #8038 - #8039 - #8040
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.
While working on better progress reporting, I realized that fetching and progress reporting really are quite different, and are best represented through different traits.
This removes several panics and implicit unused behaviors, so it acts as a really nice cleanup on top of facilitating the next few commits in the series.
There are no functional changes in this PR -- it's just refactoring.