fix: close billing and batch shutdown races - #49
Merged
Conversation
The row ack fired after every batch attempt, so an attributed request returned confirmed even when the batch had been dropped after its retries. The ack now carries committed; on false the writer makes one direct ledger_add and only then hands the row to the repair queue, which stays best-effort for every row. The three shutdown selects in drain_until fold into stopping and pause_or_stop. Hot path: an attributed request now waits for one batched ledger commit (shared with concurrent rows) before it completes; unattributed rows are unchanged. With the store down the wait is bounded by the worker's retry schedule.
The fallback test runs under a paused tokio clock so the worker's retry backoff completes instantly; the drain test now flips the shutdown watch and requires the loop to exit within two seconds instead of aborting it.
An attributed row whose batch exhausted its retries is written directly by its caller, so counting it as dropped made the shutdown flush report billing loss that did not happen.
01e6087 switched the mock transport's reply encoding from v.to_string() to serde_json::to_vec. A per-commit bisect of PR #48 on the testbed put the whole +88k instructions per 48 KB request of the big-body regression on that line (p3 4,039k vs p4 4,127k instr/req; restoring the file returns to 4,039k), while the four production groups of that commit run the same instruction stream within 0.01%. The mock transport is benchmark and demo code; production uses the HTTP transport. The remaining rps spread between builds is code placement, not added work.
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
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.
Summary
Verification
cargo fmt --allHot path
Attributed requests (a user id on the request) now wait for one batched ledger commit before completing; unattributed requests are unchanged. Measured on the testbed (pg, pool 40, oha c=256, 3 interleaved reps, 5d44be7 vs 628c802): attributed small rps 52152 -> 60873 (+16.7%), p99 11.31 -> 5.47 ms; attributed big rps 28802 -> 30815 (+7.0%), p99 21.37 -> 11.10 ms; unattributed unchanged. Under saturation the old try_send path fell through to one single-row insert per request, so the batched wait is cheaper; on an idle gateway a single attributed request pays the batch commit (0.87 ms vs 0.17 ms). With the store down the wait is bounded by the ledger worker retry schedule (8 attempts, 100 ms doubling to 30 s) plus one direct write.
Follow-ups on the branch
drain_untilfold into two helpers.