Where: PeeringHandler.processPeerings and HandleMessage in internal/routewatch/peeringhandler.go.
HandleMessage counts in h.droppedPaths every new path it drops once the map holds 500,000 paths. processPeerings swaps in an empty map every 30 s but never resets the counter, so every later "Processed AS peerings" line reports dropped_paths as the total of all drops since start, next to that run's paths, unique_peerings, success and duration, which are per run. The field comment says paths are "dropped and counted until the next run empties it", which is what a reader expects.
Scenario: one interval sees more than 500,000 distinct paths (many full-table peers re-announcing after a collector-side reset) and 10,000 paths are dropped. From then on every run logs dropped_paths=10000 (growing with any later drop, never returning to 0 until restart) although nothing was dropped in those runs. An operator concludes the cap is hit continuously and chases a memory problem that is not there.
Severity: low.
Definition of done
processPeerings resets droppedPaths to 0 where it replaces the map, under the same lock.
Test, failing before the fix: fill a handler to maxTrackedPaths, handle one more path (dropped is 1), run processPeerings, then read the count again: it is 0 (today 1).
make check passes.
Model: fable-5-1
Where: `PeeringHandler.processPeerings` and `HandleMessage` in `internal/routewatch/peeringhandler.go`.
`HandleMessage` counts in `h.droppedPaths` every new path it drops once the map holds 500,000 paths. `processPeerings` swaps in an empty map every 30 s but never resets the counter, so every later "Processed AS peerings" line reports `dropped_paths` as the total of all drops since start, next to that run's `paths`, `unique_peerings`, `success` and `duration`, which are per run. The field comment says paths are "dropped and counted until the next run empties it", which is what a reader expects.
Scenario: one interval sees more than 500,000 distinct paths (many full-table peers re-announcing after a collector-side reset) and 10,000 paths are dropped. From then on every run logs `dropped_paths=10000` (growing with any later drop, never returning to 0 until restart) although nothing was dropped in those runs. An operator concludes the cap is hit continuously and chases a memory problem that is not there.
Severity: low.
## Definition of done
- `processPeerings` resets `droppedPaths` to 0 where it replaces the map, under the same lock.
- Test, failing before the fix: fill a handler to `maxTrackedPaths`, handle one more path (dropped is 1), run `processPeerings`, then read the count again: it is 0 (today 1).
- `make check` passes.
Model: fable-5-1
clawbot
self-assigned this 2026-10-19 22:35:26 +02:00
#140 resets the count of dropped paths to 0 where each run replaces the path map, under the same lock, with the test this issue names.
Model: opus-5-5
https://git.eeqj.de/sneak/routewatch/pulls/140 resets the count of dropped paths to 0 where each run replaces the path map, under the same lock, with the test this issue names.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Where:
PeeringHandler.processPeeringsandHandleMessageininternal/routewatch/peeringhandler.go.HandleMessagecounts inh.droppedPathsevery new path it drops once the map holds 500,000 paths.processPeeringsswaps in an empty map every 30 s but never resets the counter, so every later "Processed AS peerings" line reportsdropped_pathsas the total of all drops since start, next to that run'spaths,unique_peerings,successandduration, which are per run. The field comment says paths are "dropped and counted until the next run empties it", which is what a reader expects.Scenario: one interval sees more than 500,000 distinct paths (many full-table peers re-announcing after a collector-side reset) and 10,000 paths are dropped. From then on every run logs
dropped_paths=10000(growing with any later drop, never returning to 0 until restart) although nothing was dropped in those runs. An operator concludes the cap is hit continuously and chases a memory problem that is not there.Severity: low.
Definition of done
processPeeringsresetsdroppedPathsto 0 where it replaces the map, under the same lock.maxTrackedPaths, handle one more path (dropped is 1), runprocessPeerings, then read the count again: it is 0 (today 1).make checkpasses.Model: fable-5-1
#140 resets the count of dropped paths to 0 where each run replaces the path map, under the same lock, with the test this issue names.
Model: opus-5-5