The report buffer's stop waits for the report file writes already under way before its final flush: the periodic flush's, and the one Append starts when 10 MiB are waiting. A sync.WaitGroup counts the goroutines that write report files, flushLoop included. The stop used to return at once, and the process exiting cut such a write off with its reports.
Reports a failed write kept are written by the final flush. Since #130 a failed write puts its reports back in the buffer, and the stop now waits before flushing, so the final flush writes them. The stop fails, exiting non-zero, only if that flush fails too, as README.md (Report storage) already says.
Not visible in the diff
The new tests run in a testing/synctest bubble, whose clock moves on at once when every goroutine waits: the periodic flush needs no minute, and synctest.Wait shows the stop blocked while the write is held.
The wait has no deadline of its own; fx's stop timeout bounds it, and running out exits non-zero.
Nothing appends while the buffer stops: fx stops the HTTP server first, and skips the buffer's stop if that runs out of time.
appendToThreshold is the loop TestFlushAtSizeThreshold had, moved out to be shared; startBuffer now calls the new startApp.
Judgement call: a failed write under way fails the stop only if the final flush cannot write its reports either, not on its own as the definition of done words it; that would exit non-zero with nothing lost.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/netwatch/issues/122.
## What changed
- The report buffer's stop waits for the report file writes already under way before its final flush: the periodic flush's, and the one `Append` starts when 10 MiB are waiting. A `sync.WaitGroup` counts the goroutines that write report files, `flushLoop` included. The stop used to return at once, and the process exiting cut such a write off with its reports.
- Reports a failed write kept are written by the final flush. Since https://git.eeqj.de/sneak/netwatch/pulls/130 a failed write puts its reports back in the buffer, and the stop now waits before flushing, so the final flush writes them. The stop fails, exiting non-zero, only if that flush fails too, as `README.md` (Report storage) already says.
## Not visible in the diff
- The new tests run in a `testing/synctest` bubble, whose clock moves on at once when every goroutine waits: the periodic flush needs no minute, and `synctest.Wait` shows the stop blocked while the write is held.
- The wait has no deadline of its own; fx's stop timeout bounds it, and running out exits non-zero.
- Nothing appends while the buffer stops: fx stops the HTTP server first, and skips the buffer's stop if that runs out of time.
- `appendToThreshold` is the loop `TestFlushAtSizeThreshold` had, moved out to be shared; `startBuffer` now calls the new `startApp`.
Judgement call: a failed write under way fails the stop only if the final flush cannot write its reports either, not on its own as the definition of done words it; that would exit non-zero with nothing lost.
Model: opus-5-5
PASS: #138 meets the definition of done of #122 and is ready to merge into next.
Judgement call: I accept the PR's reading that a report file write under way that fails makes the stop fail only when the final flush cannot write its reports either, since a failed write puts its reports back in memory for that flush.
Model: opus-5-5
PASS: https://git.eeqj.de/sneak/netwatch/pulls/138 meets the definition of done of https://git.eeqj.de/sneak/netwatch/issues/122 and is ready to merge into `next`.
Judgement call: I accept the PR's reading that a report file write under way that fails makes the stop fail only when the final flush cannot write its reports either, since a failed write puts its reports back in memory for that flush.
Model: opus-5-5
The report buffer's stop now waits, through a sync.WaitGroup, for
flushLoop and for the write Append starts at 10 MiB before its final
flush. It used to return at once, so the process exiting cut such a
write off and its reports were lost.
A write under way that fails puts its reports back in the buffer, so
the final flush writes them; the stop fails only if that flush fails
too.
Tests hold the periodic write and the one at 10 MiB open in a synctest
bubble and find the stop waiting until each is released; a third makes
the held write fail and finds its report written by the final flush.
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 #122.
What changed
Appendstarts when 10 MiB are waiting. Async.WaitGroupcounts the goroutines that write report files,flushLoopincluded. The stop used to return at once, and the process exiting cut such a write off with its reports.README.md(Report storage) already says.Not visible in the diff
testing/synctestbubble, whose clock moves on at once when every goroutine waits: the periodic flush needs no minute, andsynctest.Waitshows the stop blocked while the write is held.appendToThresholdis the loopTestFlushAtSizeThresholdhad, moved out to be shared;startBuffernow calls the newstartApp.Judgement call: a failed write under way fails the stop only if the final flush cannot write its reports either, not on its own as the definition of done words it; that would exit non-zero with nothing lost.
Model: opus-5-5
PASS: #138 meets the definition of done of #122 and is ready to merge into
next.Judgement call: I accept the PR's reading that a report file write under way that fails makes the stop fail only when the final flush cannot write its reports either, since a failed write puts its reports back in memory for that flush.
Model: opus-5-5
c65d14665ctoe6b4e648ce