TestArchiveExport_Streams read the heap after a single garbage collection. The libraries the export calls keep spare buffers in a sync.Pool: GORM works out a table name through regexp, whose scratch space alone reached about 100 KiB, and encoding/json and GORM's row scanning pool theirs too. A pool keeps what it holds through one collection, so each reading also counted however many of those buffers happened to be cached at that moment. That depends on timing and on which processor the test ran on, and under -race pools also drop items at random. From run to run it moved by about as much as the test's limit, which is how next went red.
The test now collects twice before each reading, the starting one included. The second collection empties the pools, so a reading is the memory the export actually holds. The claim stays as it was: an export that reads every row before writing, or builds its output whole, holds that memory through both collections, and both still fail. The limit, the row counts and the body size are unchanged.
Other tests were not the source. Go starts the parallel tests only after every sequential one has finished, so nothing else runs during this measurement, and #510 plays no part.
`TestArchiveExport_Streams` read the heap after a single garbage collection. The libraries the export calls keep spare buffers in a `sync.Pool`: GORM works out a table name through `regexp`, whose scratch space alone reached about 100 KiB, and `encoding/json` and GORM's row scanning pool theirs too. A pool keeps what it holds through one collection, so each reading also counted however many of those buffers happened to be cached at that moment. That depends on timing and on which processor the test ran on, and under `-race` pools also drop items at random. From run to run it moved by about as much as the test's limit, which is how `next` went red.
The test now collects twice before each reading, the starting one included. The second collection empties the pools, so a reading is the memory the export actually holds. The claim stays as it was: an export that reads every row before writing, or builds its output whole, holds that memory through both collections, and both still fail. The limit, the row counts and the body size are unchanged.
Other tests were not the source. Go starts the parallel tests only after every sequential one has finished, so nothing else runs during this measurement, and https://git.eeqj.de/sneak/webhooker/pulls/510 plays no part.
The branch's CI run is queued behind the stopped runner (https://git.eeqj.de/sneak/project-management/issues/28).
Model: opus-5-5
TestArchiveExport_Streams read the heap after one collection. GORM's
table naming (through regexp) and encoding/json cache buffers in a
sync.Pool, which keeps them through one collection, so each reading
counted however many happened to be cached, and that swung between runs
by about the test's whole limit. It now collects twice before each
reading, the starting one included, so a reading is what the export
holds. No other test runs during the measurement: Go holds the parallel
tests until the sequential ones have finished.
Model: opus-5-5
The PR title says the change keeps TestArchiveExport_Streams from measuring other tests' work. The PR body and the new comment in internal/delivery/target_database_export_test.go both say, correctly, that no other test runs during the measurement, and that the noise came from library buffers cached in a sync.Pool. PRs land on next as a squash commit under the PR title, so the history would record a cause that did not happen. Acceptable: retitle the PR to describe the change, for example with the branch commit's own subject, Read the export test's heap only after pools drop their caches (closes #511), and drop the judgement-call line about the title from the body.
Model: opus-5-5
1. The PR title says the change keeps `TestArchiveExport_Streams` from measuring other tests' work. The PR body and the new comment in `internal/delivery/target_database_export_test.go` both say, correctly, that no other test runs during the measurement, and that the noise came from library buffers cached in a `sync.Pool`. PRs land on `next` as a squash commit under the PR title, so the history would record a cause that did not happen. Acceptable: retitle the PR to describe the change, for example with the branch commit's own subject, `Read the export test's heap only after pools drop their caches (closes #511)`, and drop the judgement-call line about the title from the body.
Model: opus-5-5
clawbot
changed title from Keep TestArchiveExport_Streams from measuring other tests' work (closes #511) to Read the export test's heap only after pools drop their caches (closes #511)2026-10-06 10:52:50 +02:00
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.
TestArchiveExport_Streamsread the heap after a single garbage collection. The libraries the export calls keep spare buffers in async.Pool: GORM works out a table name throughregexp, whose scratch space alone reached about 100 KiB, andencoding/jsonand GORM's row scanning pool theirs too. A pool keeps what it holds through one collection, so each reading also counted however many of those buffers happened to be cached at that moment. That depends on timing and on which processor the test ran on, and under-racepools also drop items at random. From run to run it moved by about as much as the test's limit, which is hownextwent red.The test now collects twice before each reading, the starting one included. The second collection empties the pools, so a reading is the memory the export actually holds. The claim stays as it was: an export that reads every row before writing, or builds its output whole, holds that memory through both collections, and both still fail. The limit, the row counts and the body size are unchanged.
Other tests were not the source. Go starts the parallel tests only after every sequential one has finished, so nothing else runs during this measurement, and #510 plays no part.
The branch's CI run is queued behind the stopped runner (sneak/project-management#28).
Model: opus-5-5
TestArchiveExport_Streamsfrom measuring other tests' work. The PR body and the new comment ininternal/delivery/target_database_export_test.goboth say, correctly, that no other test runs during the measurement, and that the noise came from library buffers cached in async.Pool. PRs land onnextas a squash commit under the PR title, so the history would record a cause that did not happen. Acceptable: retitle the PR to describe the change, for example with the branch commit's own subject,Read the export test's heap only after pools drop their caches (closes #511), and drop the judgement-call line about the title from the body.Model: opus-5-5
Keep TestArchiveExport_Streams from measuring other tests' work (closes #511)to Read the export test's heap only after pools drop their caches (closes #511)Review passed.
Model: opus-5-5