chore(bam): remove two dead pipeline completion flags - #657
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughBAM pipeline completion tracking now relies on decompressed/grouped counters and boundary state instead of explicit flags. Decode starvation accounting and its test cases were updated for empty Q2b queues and boundary arrival conditions. ChangesBAM completion tracking
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #657 +/- ##
=======================================
Coverage 93.64% 93.65%
=======================================
Files 175 175
Lines 107492 107487 -5
=======================================
- Hits 100664 100662 -2
+ Misses 6828 6825 -3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
`decompress_done` was declared and initialized and never touched again -- never set, never read. `decode_done` was set in one place and read nowhere, so it was write-only state that looked load-bearing. Neither is missed. `Decompress` is tracked downstream through `batches_decompressed`, and `FindBoundaries` infers its completion from `batches_boundary_processed == next_read_serial`, since nothing can be processed that was not decompressed first. `Decode` is tracked by `Group` through `batches_grouped == batches_boundary_found`. Both replacement comments record that, so the next reader does not go looking for the flag. Removing `decode_done` matters for more than line count: its guard (`boundary_done && q2b_boundaries.is_empty()`) does not account for a batch sitting in a worker's `held_boundaries`, so anyone who wired the flag up to a consumer would have reintroduced the stranded-batch bug that was just fixed in `FindBoundaries`. Deleting it removes that trap rather than leaving a loaded gun behind a plausible-looking name. Dropping the store leaves the `else if` arm that recorded Q2b starvation as the only live branch, so the two `state.stats()` blocks fold into one. The recording condition is unchanged -- `!(boundary_done && q2b empty)` becomes the De Morgan equivalent -- and the comment now says why an empty Q2b past that point is the terminal state rather than a stall. That arm had no test, so rewriting it dropped patch coverage to zero on the three lines it touches: `state.stats()` is `None` unless stats collection is enabled, which nothing turned on. It is covered now, which also turns the "condition unchanged" claim above into something checked rather than asserted -- inverting the condition fails both cases. Both fields were `pub` on `BamPipelineState`, which is internal pipeline machinery with no reader outside this module.
737e11c to
da5d018
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
Follow-up to #656, found while auditing
BamPipelineState's completion graph. Independent of that PR — this branches frommainand touches none of the same lines.Two
*_doneflags were dead:decompress_donedecode_doneNeither is missed
Decompressis tracked downstream throughbatches_decompressed, andFindBoundariesinfers its completion frombatches_boundary_processed == next_read_serial— nothing can be processed that was not decompressed first.Decodeis tracked byGroupthroughbatches_grouped == batches_boundary_found.Both are recorded as comments where the fields were, so the next reader doesn't go looking for a flag that was deliberately removed.
Why
decode_doneis worth deleting rather than leavingIts guard was
boundary_done && q2b_boundaries.is_empty(), which does not account for a batch sitting in a worker'sheld_boundaries. Anyone who wired the flag up to a consumer would have reintroduced exactly the stranded-batch bug #656 fixes inFindBoundaries— the flag is inert today only by accident. Deleting it removes the trap instead of leaving a loaded gun behind a plausible-looking name.Behavior
Unchanged. Dropping the store left the
else ifarm that records Q2b starvation as the only live branch, so the twostate.stats()blocks fold into one. The recording condition is the De Morgan equivalent of the original (!(boundary_done && q2b empty)), and the comment now explains why an empty Q2b past that point is the terminal state rather than a stall.Both fields were
pubonBamPipelineState— internal pipeline machinery with no reader outside the module.cargo ci-test(6586 tests),ci-fmt,ci-lint, andci-docall pass.Coverage
Rewriting that stats arm dropped patch coverage to 0% on the three lines it touches —
state.stats()isNoneunless stats collection is enabled, and nothing turned it on, so the arm had never been exercised. It is covered now bytest_decode_records_q2_starvation_only_while_boundaries_may_arrive, which also turns the "condition unchanged" claim above into something checked rather than asserted: inverting the condition fails both cases.Summary by CodeRabbit