Scanner status tests fail under host load on a 100 ms timer #124

New Issue

2026-10-04T03:32:29+02:00

clawbot commented

2026-10-04 03:32:29 +02:00

Problem

TestSendScanStatusNonBlocking and TestSendEnumerateStatusNonBlocking in mfer/scanner_test.go run the send in a goroutine and fail if it has not finished within 100 ms of wall-clock time. On a loaded host the goroutine can simply not be scheduled in time, so make test fails for no fault in the code. A reviewer hit this on next while the host load average was about 90; the rerun passed.

Definition of done

Both tests check that the send does not block without depending on how fast the host is (for example, testing/synctest, or calling the send directly so a blocking send fails the test instead of a timer).
No other test in the repo fails on a wall-clock limit this short; any found gets the same fix.
make check passes.
Commit title ends with (closes #N) for this issue's number.

Model: opus-5-5

## Problem `TestSendScanStatusNonBlocking` and `TestSendEnumerateStatusNonBlocking` in `mfer/scanner_test.go` run the send in a goroutine and fail if it has not finished within 100 ms of wall-clock time. On a loaded host the goroutine can simply not be scheduled in time, so `make test` fails for no fault in the code. A reviewer hit this on `next` while the host load average was about 90; the rerun passed. ## Definition of done - Both tests check that the send does not block without depending on how fast the host is (for example, `testing/synctest`, or calling the send directly so a blocking send fails the test instead of a timer). - No other test in the repo fails on a wall-clock limit this short; any found gets the same fix. - `make check` passes. - Commit title ends with ` (closes #N)` for this issue's number. Model: opus-5-5

clawbot referenced this issue

2026-10-04 05:51:13 +02:00

Give -v to verbose, move --version to -V (closes #64) #107

clawbot referenced this issue from a commit

2026-10-04 08:03:12 +02:00

Scanner status tests no longer depend on a 100 ms timer (closes #124)

clawbot referenced a pull request that will close this issue

2026-10-04 08:12:26 +02:00

Scanner status tests no longer depend on a 100 ms timer (closes #124) #132

clawbot commented

2026-10-04 08:12:33 +02:00

Implemented in #132. The two scanner status tests now call the send directly, so a send that blocked would hang the test until its timeout. They no longer race a 100 ms timer. The search for other short timers found one more test with the same problem: the gpg test for a child that holds gpg's output. It now waits on a named pipe until the fake gpg has started its child, then cancels.

Model: opus-5-5

Implemented in https://git.eeqj.de/sneak/mfer/pulls/132. The two scanner status tests now call the send directly, so a send that blocked would hang the test until its timeout. They no longer race a 100 ms timer. The search for other short timers found one more test with the same problem: the gpg test for a child that holds gpg's output. It now waits on a named pipe until the fake gpg has started its child, then cancels. Model: opus-5-5

clawbot referenced this issue from a commit

2026-10-04 09:14:07 +02:00

Scanner status tests no longer depend on a 100 ms timer (closes #124)

clawbot closed this issue

2026-10-04 09:48:52 +02:00

clawbot referenced this issue from a commit

2026-10-04 09:48:53 +02:00

Scanner status tests no longer depend on a 100 ms timer (closes #124)

clawbot referenced this issue

2026-10-04 10:04:11 +02:00

1.0.0 milestone #92

Sign in to join this conversation.