Conversation
Reserving them one by one in a single transaction is both slow --N rounds of quant queries instead of one per batch-- and fragile: a single failing reservation aborts the whole transaction, so none of the pending reservations ends up assigned, not even the ones already processed, and there is no retry until the next run. On the database where this was found the sweep had been dying every night for weeks, some nights on a bad piece of data and others on a serialization conflict, and nobody noticed until its consequences showed up elsewhere: a reservation that never grabs its goods keeps its requested quantity alive, and the replenishment computation then reads it as uncovered demand and buys stock that is already in the warehouse. Each batch now runs in its own savepoint, so a batch that fails is skipped and the sweep goes on with the next one. The batch size comes from the stock_reserve.assign_batch_size system parameter and is 50 when it is not set; a size of 0 is raised to 1, since split_every would otherwise loop forever. Tests: six cases -- the sweep assigning the pending reservations, a failing batch skipped without raising, a failing batch not stopping the next one, the size read from the parameter, the default of 50 when the parameter is absent, and the empty sweep. MSG 2>&1 | python3 "/home/marcos/develop/gextia-dev/tools/token-killer.py" --mode generic
amarcosg
force-pushed
the
16.0-fix-stock_reserve-assign-sweep-batches
branch
from
August 26, 2026 16:33
e53c6fd to
a3b2e15
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reserving them one by one in a single transaction is both slow --N rounds of quant queries instead of one per batch-- and fragile: a single failing reservation aborts the whole transaction, so none of the pending reservations ends up assigned, not even the ones already processed, and there is no retry until the next run.
Each batch now runs in its own savepoint, so a batch that fails is skipped and the sweep goes on with the next one. The batch size comes from the stock_reserve.assign_batch_size system parameter and is 50 when it is not set; a size of 0 is raised to 1, since split_every would otherwise loop forever.
Tests: six cases -- the sweep assigning the pending reservations, a failing batch skipped without raising, a failing batch not stopping the next one, the size read from the parameter, the default of 50 when the parameter is absent, and the empty sweep.