Cause: the test counted active as stale whenever its PONG took more than 500 ms to arrive, which happens on a loaded build host. The code was right.
The test used to sleep 500 ms, have active send PING, and then ask GetStaleOrphanSessions for sessions last seen before the current time minus 500 ms. It now reads the clock once after both users have registered and before active sends its PING, and passes that time as the cutoff. idle was last seen when it registered, before the cutoff, and active's PING is recorded after it, so the result follows from the order of events. If handleMessage stopped recording a user's activity, active would still be last seen at registration and the test would fail.
Both readings in #181 were checked against the code: the IRC listener records the activity in handleMessage before the command's handler replies, and the SQLite driver stores the last-seen time as text that keeps the nanoseconds. A temporary diagnostic (not committed) caught a failing run in which the server had recorded the PING at once but the PONG reached the test more than 500 ms later.
Judgement call: the test relies on the wall clock not stepping backwards between the cutoff and the PING, since the stored time and the cutoff both come from it.
Model: opus-5-5
Cause: the test counted `active` as stale whenever its `PONG` took more than 500 ms to arrive, which happens on a loaded build host. The code was right.
The test used to sleep 500 ms, have `active` send `PING`, and then ask `GetStaleOrphanSessions` for sessions last seen before the current time minus 500 ms. It now reads the clock once after both users have registered and before `active` sends its `PING`, and passes that time as the cutoff. `idle` was last seen when it registered, before the cutoff, and `active`'s `PING` is recorded after it, so the result follows from the order of events. If `handleMessage` stopped recording a user's activity, `active` would still be last seen at registration and the test would fail.
Both readings in https://git.eeqj.de/sneak/neoirc/issues/181 were checked against the code: the IRC listener records the activity in `handleMessage` before the command's handler replies, and the SQLite driver stores the last-seen time as text that keeps the nanoseconds. A temporary diagnostic (not committed) caught a failing run in which the server had recorded the `PING` at once but the `PONG` reached the test more than 500 ms later.
Judgement call: the test relies on the wall clock not stepping backwards between the cutoff and the `PING`, since the stored time and the cutoff both come from it.
Model: opus-5-5
The test slept 500 ms, had active send PING, then asked for sessions
last seen before now minus 500 ms. On a loaded host the PONG can take
more than 500 ms to arrive, which puts active's last-seen time before
that cutoff. The code is right: it records the time before it replies,
to the nanosecond.
The test now takes the cutoff after both users register and before
active's PING, so the result follows from the order of events alone.
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.
Cause: the test counted
activeas stale whenever itsPONGtook more than 500 ms to arrive, which happens on a loaded build host. The code was right.The test used to sleep 500 ms, have
activesendPING, and then askGetStaleOrphanSessionsfor sessions last seen before the current time minus 500 ms. It now reads the clock once after both users have registered and beforeactivesends itsPING, and passes that time as the cutoff.idlewas last seen when it registered, before the cutoff, andactive'sPINGis recorded after it, so the result follows from the order of events. IfhandleMessagestopped recording a user's activity,activewould still be last seen at registration and the test would fail.Both readings in #181 were checked against the code: the IRC listener records the activity in
handleMessagebefore the command's handler replies, and the SQLite driver stores the last-seen time as text that keeps the nanoseconds. A temporary diagnostic (not committed) caught a failing run in which the server had recorded thePINGat once but thePONGreached the test more than 500 ms later.Judgement call: the test relies on the wall clock not stepping backwards between the cutoff and the
PING, since the stored time and the cutoff both come from it.Model: opus-5-5
clawbot referenced this pull request2026-10-21 12:10:31 +02:00
Review passed: the stated cause matches the code, and the test change makes the result follow from the order of events.
Model: opus-5-5