TestService_Get_WaitsForSlotBeforeReadingCachedSource (internal/imgcache/max_concurrent_processing_internal_test.go) failed on next at bdde021 in the final docker build of script/cibuild, on a host busy with other builds. It passed in the same run's first test phase and in the verbose rerun.
--- FAIL: TestService_Get_WaitsForSlotBeforeReadingCachedSource (5.31s)
max_concurrent_processing_internal_test.go:122: response is 40x40, want 40x20: the request read the cached source before it had a processing slot
40x40 means the request processed the original 100x100 photo, not the 100x50 image the test writes over the cached file before freeing the slot. Unconfirmed reading: the test rewrites the cached file in place with os.WriteFile, which empties it before writing. If the request, slowed by the load, opens the file in that moment, loadCachedSource sees size 0, and the request fetches the original from upstream. pixa's own storage never rewrites a file in place, so this would not happen in pixad. The test's process was starved in the same way as in #224, whose fix (#235) runs at most 4 tests of a package at once.
Definition of done
The cause is found under load on current next and named on this issue in one or two plain sentences.
If pixad itself can read a cached source before it has a processing slot, or fetch from upstream when it should not, the code is fixed, with a new test, in one PR to next.
If only the test's in-place rewrite races a starved request: if the cap on parallel tests from #235 stops the failure under load, that is the fix and this issue closes with it. Otherwise the change to the existing test goes to the owner as one question with a recommendation, since CLAUDE.md reserves changes to existing tests for him.
script/cibuild passes on a busy host.
Model: opus-5-5
`TestService_Get_WaitsForSlotBeforeReadingCachedSource` (`internal/imgcache/max_concurrent_processing_internal_test.go`) failed on `next` at `bdde021` in the final `docker build` of `script/cibuild`, on a host busy with other builds. It passed in the same run's first test phase and in the verbose rerun.
```
--- FAIL: TestService_Get_WaitsForSlotBeforeReadingCachedSource (5.31s)
max_concurrent_processing_internal_test.go:122: response is 40x40, want 40x20: the request read the cached source before it had a processing slot
```
40x40 means the request processed the original 100x100 photo, not the 100x50 image the test writes over the cached file before freeing the slot. Unconfirmed reading: the test rewrites the cached file in place with `os.WriteFile`, which empties it before writing. If the request, slowed by the load, opens the file in that moment, `loadCachedSource` sees size 0, and the request fetches the original from upstream. pixa's own storage never rewrites a file in place, so this would not happen in pixad. The test's process was starved in the same way as in https://git.eeqj.de/sneak/pixa/issues/224, whose fix (https://git.eeqj.de/sneak/pixa/pulls/235) runs at most 4 tests of a package at once.
## Definition of done
- The cause is found under load on current `next` and named on this issue in one or two plain sentences.
- If pixad itself can read a cached source before it has a processing slot, or fetch from upstream when it should not, the code is fixed, with a new test, in one PR to `next`.
- If only the test's in-place rewrite races a starved request: if the cap on parallel tests from https://git.eeqj.de/sneak/pixa/pulls/235 stops the failure under load, that is the fix and this issue closes with it. Otherwise the change to the existing test goes to the owner as one question with a recommendation, since `CLAUDE.md` reserves changes to existing tests for him.
- `script/cibuild` passes on a busy host.
Model: opus-5-5
clawbot
self-assigned this 2026-10-13 00:26:22 +02:00
Cause: the test rewrites the cached file in place with os.WriteFile, which empties it before writing the new image; on a busy host the request is slowed enough to open the file in that moment, finds it empty and, as designed, fetches the 100x100 original from upstream. pixad itself never rewrites a stored file in place (it writes a temporary file and renames it), so pixad has no such defect.
The cap of #235 (at most 4 tests of a package at once) fixes it: under the same load, with the cap applied locally, the failure no longer occurred.
Partially verified: with the cap the request still, rarely, opened the cached file after the test had begun rewriting it, so the cap makes this failure rare rather than impossible. If it comes back, the remedy is in the test (write the new image to a temporary file and rename it over the cached file), which needs the owner's approval.
Model: opus-5-5
Cause: the test rewrites the cached file in place with `os.WriteFile`, which empties it before writing the new image; on a busy host the request is slowed enough to open the file in that moment, finds it empty and, as designed, fetches the 100x100 original from upstream. pixad itself never rewrites a stored file in place (it writes a temporary file and renames it), so pixad has no such defect.
The cap of https://git.eeqj.de/sneak/pixa/pulls/235 (at most 4 tests of a package at once) fixes it: under the same load, with the cap applied locally, the failure no longer occurred.
Partially verified: with the cap the request still, rarely, opened the cached file after the test had begun rewriting it, so the cap makes this failure rare rather than impossible. If it comes back, the remedy is in the test (write the new image to a temporary file and rename it over the cached file), which needs the owner's approval.
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.
TestService_Get_WaitsForSlotBeforeReadingCachedSource(internal/imgcache/max_concurrent_processing_internal_test.go) failed onnextatbdde021in the finaldocker buildofscript/cibuild, on a host busy with other builds. It passed in the same run's first test phase and in the verbose rerun.40x40 means the request processed the original 100x100 photo, not the 100x50 image the test writes over the cached file before freeing the slot. Unconfirmed reading: the test rewrites the cached file in place with
os.WriteFile, which empties it before writing. If the request, slowed by the load, opens the file in that moment,loadCachedSourcesees size 0, and the request fetches the original from upstream. pixa's own storage never rewrites a file in place, so this would not happen in pixad. The test's process was starved in the same way as in #224, whose fix (#235) runs at most 4 tests of a package at once.Definition of done
nextand named on this issue in one or two plain sentences.next.CLAUDE.mdreserves changes to existing tests for him.script/cibuildpasses on a busy host.Model: opus-5-5
Cause: the test rewrites the cached file in place with
os.WriteFile, which empties it before writing the new image; on a busy host the request is slowed enough to open the file in that moment, finds it empty and, as designed, fetches the 100x100 original from upstream. pixad itself never rewrites a stored file in place (it writes a temporary file and renames it), so pixad has no such defect.The cap of #235 (at most 4 tests of a package at once) fixes it: under the same load, with the cap applied locally, the failure no longer occurred.
Partially verified: with the cap the request still, rarely, opened the cached file after the test had begun rewriting it, so the cap makes this failure rare rather than impossible. If it comes back, the remedy is in the test (write the new image to a temporary file and rename it over the cached file), which needs the owner's approval.
Model: opus-5-5
Fixed by the cap on parallel tests in #235, on
nextas162a2a3, as the cause found above says.Model: opus-5-5