TestEvictionRunsOnPeriodicSchedule wrote each variant file and then inserted its accounting row by hand while the evictor ran every 100 ms. When a reconciliation pass landed between the two steps, it adopted the file first, the hand insert failed on the unique key, and next failed make test now and then.
The test no longer inserts rows. Before starting the evictor it takes the test database's only connection, then waits until the evictor's startup pass is blocked on it. By then that pass has already walked the variant directory, which was still empty. The test then writes the three files directly to storage, not through StoreVariant, so no write-pressure notification fires, and releases the connection. Only a periodic reconciliation pass can adopt the files, and only the eviction pass that follows it can evict them. The test waits until two of the three files are gone, then checks that usage is within the limit and that no row points at a missing file. TestStopEvictionInterruptsPassInProgress already holds the connection the same way.
This changes only the test. No other test in internal/imgcache inserts a row by hand after starting the evictor.
Judgement call: the test now relies on reconciliation adopting the files, as the plan suggested. In exchange it proves the periodic schedule on every run. Before, a slow start could let the startup pass do the eviction.
Left as is: TestPeriodicReconciliationAdoptsFileThatAppearsAfterStartup still waits for the startup pass with a fixed sleep. It cannot fail because of that, but a slow start can let it pass without proving its claim.
Model: opus-5-5
`TestEvictionRunsOnPeriodicSchedule` wrote each variant file and then inserted its accounting row by hand while the evictor ran every 100 ms. When a reconciliation pass landed between the two steps, it adopted the file first, the hand insert failed on the unique key, and `next` failed `make test` now and then.
The test no longer inserts rows. Before starting the evictor it takes the test database's only connection, then waits until the evictor's startup pass is blocked on it. By then that pass has already walked the variant directory, which was still empty. The test then writes the three files directly to storage, not through `StoreVariant`, so no write-pressure notification fires, and releases the connection. Only a periodic reconciliation pass can adopt the files, and only the eviction pass that follows it can evict them. The test waits until two of the three files are gone, then checks that usage is within the limit and that no row points at a missing file. `TestStopEvictionInterruptsPassInProgress` already holds the connection the same way.
This changes only the test. No other test in `internal/imgcache` inserts a row by hand after starting the evictor.
- Judgement call: the test now relies on reconciliation adopting the files, as the plan suggested. In exchange it proves the periodic schedule on every run. Before, a slow start could let the startup pass do the eviction.
- Left as is: `TestPeriodicReconciliationAdoptsFileThatAppearsAfterStartup` still waits for the startup pass with a fixed sleep. It cannot fail because of that, but a slow start can let it pass without proving its claim.
Model: opus-5-5
The test wrote each variant file and then inserted its accounting row by
hand while the evictor was running. A reconciliation pass between the two
steps adopted the file first, and the hand insert failed on the unique key.
The test now writes the files only, while it holds the test database's
only connection, so the evictor's startup pass waits after walking the
still empty variant directory. A periodic reconciliation pass then adopts
the files and the eviction pass after it evicts them; no write-pressure
notification fires. The test waits until two of the three files are gone,
then checks that usage is within the limit and that no row points at a
missing file.
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.
TestEvictionRunsOnPeriodicSchedulewrote each variant file and then inserted its accounting row by hand while the evictor ran every 100 ms. When a reconciliation pass landed between the two steps, it adopted the file first, the hand insert failed on the unique key, andnextfailedmake testnow and then.The test no longer inserts rows. Before starting the evictor it takes the test database's only connection, then waits until the evictor's startup pass is blocked on it. By then that pass has already walked the variant directory, which was still empty. The test then writes the three files directly to storage, not through
StoreVariant, so no write-pressure notification fires, and releases the connection. Only a periodic reconciliation pass can adopt the files, and only the eviction pass that follows it can evict them. The test waits until two of the three files are gone, then checks that usage is within the limit and that no row points at a missing file.TestStopEvictionInterruptsPassInProgressalready holds the connection the same way.This changes only the test. No other test in
internal/imgcacheinserts a row by hand after starting the evictor.TestPeriodicReconciliationAdoptsFileThatAppearsAfterStartupstill waits for the startup pass with a fixed sleep. It cannot fail because of that, but a slow start can let it pass without proving its claim.Model: opus-5-5
PASS
d6a7bd9ab67d7eeafbf3a79fb6db04c6938b1773, rebased ontonextatbe6c715b36dfa7bb490dec41983477f37a9b4b6b.Model: opus-5-5