fix(announce): make cold-start tracker discovery fast and visible - #446
Merged
Conversation
On a cold start the dashboard sat on "Waiting for trackers" long after
Tor was up. Three causes, all in the announce path:
1. The boot announce pass walked xites strictly serially, and each
xite's pass waits out its slowest tracker (75s ceiling). Dozens of
xites with the usual dead trackers ground the first pass out for
tens of minutes, and the loop could not react to anything while it
ran. Passes now announce xites four at a time; measured on a live
node, the first verdict batch lands within a couple of minutes of
launch instead of zero announces after three.
2. Nothing re-announced when a transport came up. Onion trackers gated
during the pre-Tor boot pass stayed untried until the next periodic
pass, up to 20 minutes away. set_tor_status and set_i2p_status now
fire trackers_changed on a state move, so the announce loop runs
again seconds after Tor or I2P comes up.
3. A tracker only entered announcerStats after its announce resolved,
and gated entries were filtered out entirely, so the stats map was
empty for the whole cold-start window. A pass now seeds every
tracker it is about to try as "announcing" (pushed immediately),
and announcerStats {planned: true} also returns overlay-gated
entries so the health drawer can list everything the node will try.
The default answer stays gated-free for older dashboards, which
count every returned entry in their health ratio.
|
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
Fixes the cold-start "Waiting for trackers" report: the dashboard sat on that label long after Tor was up, with an empty tracker card.
Cause 1: the boot announce pass was serial and slow
The announce loop walked xites strictly one at a time, and each xite's pass waits out its slowest tracker (75s ceiling). Dozens of xites times the usual dead trackers ground the first pass out for tens of minutes. While it ran, the loop could react to nothing. Measured before the fix: zero
Announcedlines three minutes after launch. Passes now announce xites four at a time through a semaphore; measured after, the first batch of verdicts (8 xites, real peer counts) landed within a couple of minutes of a cold launch.Cause 2: nothing re-announced when a transport came up
Onion trackers gated during the pre-Tor boot pass stayed untried until the next periodic pass, up to 20 minutes away.
set_tor_statusandset_i2p_statusnow firetrackers_changedon a state move, so the announce loop runs again seconds after Tor or I2P comes up. The notify stores a permit, so a transition during an in-flight pass queues exactly one rerun.Cause 3: the stats map was empty until announces resolved
A tracker only entered
announcerStatsafter its announce resolved, and overlay-gated entries were filtered out entirely. During the whole cold-start window the map was empty, which is exactly the dashboard's "Waiting for trackers" state. Now:"announcing"and pushesannouncerChangedimmediately, so rows appear within seconds. A tracker with a verdict keeps showing that verdict while a retry is in flight.announcerStats {planned: true}also returns overlay-gated entries, so the health drawer can list every tracker the node plans to try once Tor/I2P is up. The default answer stays gated-free on purpose: shipped dashboards count every returned entry in their health ratio.Dashboard counterpart
EpixDash-Xite PR (same branch name) polls with
planned: true, merges pushed stats instead of replacing them, counts only verdict rows (announced/error) in the health ratio, and renders announcing/gated rows with a status note. Until it is deployed, the shipped dashboard may briefly show "0 of N answering" during the first announce pass instead of "Waiting for trackers"; verdicts land within a minute or two either way.Testing
cargo test -p epix-ui --lib tracker: 10 passed.