What is wrong. Under steady traffic the timed writes of the prefix, AS and peer handlers happen only on every other tick. Each flush loop skips a tick unless at least one interval has passed since lastFlush, and a write sets lastFlush when it ends. The next tick then comes a little less than one interval later, so it is skipped. The prefix handler, including the routing table's changes, writes about every 2 seconds, and the AS and peer handlers about every 4, where the README and the code comments say 1, 2 and 2.
What acceptable looks like. A timed write happens on every tick whose interval has passed since the last write started, so writes follow the documented intervals; or, if a longer interval is intended, the README and the constants say so. A full batch still wakes the loop at once.
Definition of done.
A test with a controlled clock or ticker that fails on the current code: two ticks one interval apart with a write between them both write.
The fix in internal/routewatch, after #189, which touches the same loops.
One reviewed PR into next.
Model: opus-5-5
**What is wrong.** Under steady traffic the timed writes of the prefix, AS and peer handlers happen only on every other tick. Each flush loop skips a tick unless at least one interval has passed since `lastFlush`, and a write sets `lastFlush` when it ends. The next tick then comes a little less than one interval later, so it is skipped. The prefix handler, including the routing table's changes, writes about every 2 seconds, and the AS and peer handlers about every 4, where the README and the code comments say 1, 2 and 2.
**What acceptable looks like.** A timed write happens on every tick whose interval has passed since the last write started, so writes follow the documented intervals; or, if a longer interval is intended, the README and the constants say so. A full batch still wakes the loop at once.
**Definition of done.**
- A test with a controlled clock or ticker that fails on the current code: two ticks one interval apart with a write between them both write.
- The fix in `internal/routewatch`, after https://git.eeqj.de/sneak/routewatch/issues/189, which touches the same loops.
- One reviewed PR into `next`.
Model: opus-5-5
clawbot
self-assigned this 2026-10-27 14:00:23 +01:00
#193 makes every tick of the flush timer write. A full batch's write restarts the timer as it begins, so the next timed write comes one interval after that write began. The PR says why the timer restarts instead of comparing recorded times.
Model: opus-5-5
https://git.eeqj.de/sneak/routewatch/pulls/193 makes every tick of the flush timer write. A full batch's write restarts the timer as it begins, so the next timed write comes one interval after that write began. The PR says why the timer restarts instead of comparing recorded times.
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.
What is wrong. Under steady traffic the timed writes of the prefix, AS and peer handlers happen only on every other tick. Each flush loop skips a tick unless at least one interval has passed since
lastFlush, and a write setslastFlushwhen it ends. The next tick then comes a little less than one interval later, so it is skipped. The prefix handler, including the routing table's changes, writes about every 2 seconds, and the AS and peer handlers about every 4, where the README and the code comments say 1, 2 and 2.What acceptable looks like. A timed write happens on every tick whose interval has passed since the last write started, so writes follow the documented intervals; or, if a longer interval is intended, the README and the constants say so. A full batch still wakes the loop at once.
Definition of done.
internal/routewatch, after #189, which touches the same loops.next.Model: opus-5-5
#193 makes every tick of the flush timer write. A full batch's write restarts the timer as it begins, so the next timed write comes one interval after that write began. The PR says why the timer restarts instead of comparing recorded times.
Model: opus-5-5