Each processing run of the peering handler replaced its path map but kept the count of paths dropped while the map was full. Every later "Processed AS peerings" log line therefore reported dropped_paths as the total since start, next to paths, unique_peerings, success and duration, which are the run's own. processPeerings now sets the count to 0 where it replaces the map, under the same lock, so dropped_paths covers only the run it is logged with.
Not visible in the diff: a run that finds the map empty returns before it logs. The count is still reset there, and it is 0 anyway, since a path is dropped only while the map is full.
The new test fills the map to its limit with paths of one AS, which carry no peering, so the run records nothing; one more path is dropped, and after the run the count is 0 again.
Judgement call: TODO.md is unchanged, as with the other audit fixes on next.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/routewatch/issues/116.
Each processing run of the peering handler replaced its path map but kept the count of paths dropped while the map was full. Every later "Processed AS peerings" log line therefore reported `dropped_paths` as the total since start, next to `paths`, `unique_peerings`, `success` and `duration`, which are the run's own. `processPeerings` now sets the count to 0 where it replaces the map, under the same lock, so `dropped_paths` covers only the run it is logged with.
Not visible in the diff: a run that finds the map empty returns before it logs. The count is still reset there, and it is 0 anyway, since a path is dropped only while the map is full.
The new test fills the map to its limit with paths of one AS, which carry no peering, so the run records nothing; one more path is dropped, and after the run the count is 0 again.
Judgement call: `TODO.md` is unchanged, as with the other audit fixes on `next`.
Model: opus-5-5
processPeerings replaced the path map every run but kept the count of
paths dropped while the map was full, so every later "Processed AS
peerings" line reported all drops since start next to that run's own
figures. The count is now set to 0 where the map is replaced, under the
same lock. A test fills the map, has one path dropped, runs the
processing and finds the count back at 0.
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.
Fixes #116.
Each processing run of the peering handler replaced its path map but kept the count of paths dropped while the map was full. Every later "Processed AS peerings" log line therefore reported
dropped_pathsas the total since start, next topaths,unique_peerings,successandduration, which are the run's own.processPeeringsnow sets the count to 0 where it replaces the map, under the same lock, sodropped_pathscovers only the run it is logged with.Not visible in the diff: a run that finds the map empty returns before it logs. The count is still reset there, and it is 0 anyway, since a path is dropped only while the map is full.
The new test fills the map to its limit with paths of one AS, which carry no peering, so the run records nothing; one more path is dropped, and after the run the count is 0 again.
Judgement call:
TODO.mdis unchanged, as with the other audit fixes onnext.Model: opus-5-5
Review passed.
Model: opus-5-5