Repository navigation
refactor(bam-io): collapse the duplicated grouping domain types onto one definition (R0b) - #741
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 50 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (6)
Note Reviews pausedUse the following commands to manage reviews:
Use the checkboxes below for quick actions:
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)
WalkthroughThe change centralizes grouping and library APIs in ChangesShared BAM I/O API migration
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This change consolidates duplicate grouping types through re-exports without changing behavior. No actionable merge-blocking risk remains after normal checks and review. Suggested labels: 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
Comment |
|
@coderabbitai pause |
✅ Action performedReviews paused. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main-runall #741 +/- ##
==============================================
Coverage ? 94.02%
==============================================
Files ? 248
Lines ? 130233
Branches ? 0
==============================================
Hits ? 122454
Misses ? 7779
Partials ? 0 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
35c0479 to
0d307d1
Compare
972ecea to
c55ac1d
Compare
0d307d1 to
dc37ab7
Compare
c55ac1d to
b0fc25c
Compare
dc37ab7 to
410ca1f
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/lib/read_info.rs`:
- Around line 20-26: Remove the local UNKNOWN_LIBRARY static and update every
ReadInfo fallback that references it to call the re-exported unknown_library()
function from fgumi_bam_io. Preserve the existing fallback behavior and keep the
public re-export unchanged.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 5dac1291-161d-439b-b48f-8007e27eab14
📒 Files selected for processing (6)
crates/fgumi-bam-io/src/grouping.rscrates/fgumi-bam-io/src/lib.rssrc/lib/grouper.rssrc/lib/read_info.rssrc/lib/unified_pipeline/bam.rssrc/lib/unified_pipeline/base.rs
b0fc25c to
dfe6609
Compare
410ca1f to
ba6ab62
Compare
dfe6609 to
538a950
Compare
ba6ab62 to
94a0192
Compare
538a950 to
2f80104
Compare
94a0192 to
fbccad8
Compare
fbccad8 to
ee99214
Compare
|
Fixed. The local Worth naming why this one stings: it is the PR's own thesis violated one level down. The change collapses duplicated types onto a single definition, and I re-exported No behavior changed: nothing compares library Sibling audit for the same mistake across the rest of the change: the other statics in the touched files are The re-export comment now explains the value-level duplication too, so the next reader sees why there is no local static. 8439 tests passing, all static gates green. |
|
@coderabbitai review |
|
2f80104 to
a548ad0
Compare
ee99214 to
35ad7ab
Compare
35ad7ab to
c84c92d
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
a548ad0 to
559b2f7
Compare
c84c92d to
c4bfe36
Compare
…one definition `DecodedRecord`, `GroupKey`, `GroupKeyConfig`, `LibraryIndex`, `LibraryLookup`, `build_library_lookup`, and the `Grouper` trait each existed twice: once in `fgumi-bam-io` (ported in #734) and once in `unified_pipeline` / `read_info`. The copies were textually identical apart from field visibility and doc formatting, and the duplication was deliberate — #734 left the umbrella copies in place so nothing had to be rewired. That worked while the ported step library only ever *produced* these values. It stops working at the first ported step that hands one to an umbrella grouper: `GroupBam` calls `TemplateGrouper::add_records`, and the two identical definitions are two incompatible types, so the call cannot be written at all. Keep the `fgumi-bam-io` definition and re-export it from both former homes, so every existing `crate::unified_pipeline::DecodedRecord` and `crate::read_info::LibraryIndex` path resolves unchanged. Two supporting changes fall out: - `GroupKey::has_mate_position` only existed on the umbrella copy; ported to `fgumi-bam-io` so the surviving definition is a superset of both. - `grouper.rs` reached into `DecodedRecord`'s fields directly, which are private on the `fgumi-bam-io` copy (made so during #734's review). Those five sites now go through `into_raw_bytes` / `record` / `raw_bytes`, which is what the accessors are for. Net -483 lines with no behavior change; the full suite is unchanged at 8322.
c4bfe36 to
607a8eb
Compare
|
@coderabbitai review |
|
|
@coderabbitai full review |
|
…one definition (#741) `DecodedRecord`, `GroupKey`, `GroupKeyConfig`, `LibraryIndex`, `LibraryLookup`, `build_library_lookup`, and the `Grouper` trait each existed twice: once in `fgumi-bam-io` (ported in #734) and once in `unified_pipeline` / `read_info`. The copies were textually identical apart from field visibility and doc formatting, and the duplication was deliberate — #734 left the umbrella copies in place so nothing had to be rewired. That worked while the ported step library only ever *produced* these values. It stops working at the first ported step that hands one to an umbrella grouper: `GroupBam` calls `TemplateGrouper::add_records`, and the two identical definitions are two incompatible types, so the call cannot be written at all. Keep the `fgumi-bam-io` definition and re-export it from both former homes, so every existing `crate::unified_pipeline::DecodedRecord` and `crate::read_info::LibraryIndex` path resolves unchanged. Two supporting changes fall out: - `GroupKey::has_mate_position` only existed on the umbrella copy; ported to `fgumi-bam-io` so the surviving definition is a superset of both. - `grouper.rs` reached into `DecodedRecord`'s fields directly, which are private on the `fgumi-bam-io` copy (made so during #734's review). Those five sites now go through `into_raw_bytes` / `record` / `raw_bytes`, which is what the accessors are for. Net -483 lines with no behavior change; the full suite is unchanged at 8322.
…one definition (#741) `DecodedRecord`, `GroupKey`, `GroupKeyConfig`, `LibraryIndex`, `LibraryLookup`, `build_library_lookup`, and the `Grouper` trait each existed twice: once in `fgumi-bam-io` (ported in #734) and once in `unified_pipeline` / `read_info`. The copies were textually identical apart from field visibility and doc formatting, and the duplication was deliberate — #734 left the umbrella copies in place so nothing had to be rewired. That worked while the ported step library only ever *produced* these values. It stops working at the first ported step that hands one to an umbrella grouper: `GroupBam` calls `TemplateGrouper::add_records`, and the two identical definitions are two incompatible types, so the call cannot be written at all. Keep the `fgumi-bam-io` definition and re-export it from both former homes, so every existing `crate::unified_pipeline::DecodedRecord` and `crate::read_info::LibraryIndex` path resolves unchanged. Two supporting changes fall out: - `GroupKey::has_mate_position` only existed on the umbrella copy; ported to `fgumi-bam-io` so the surviving definition is a superset of both. - `grouper.rs` reached into `DecodedRecord`'s fields directly, which are private on the `fgumi-bam-io` copy (made so during #734's review). Those five sites now go through `into_raw_bytes` / `record` / `raw_bytes`, which is what the accessors are for. Net -483 lines with no behavior change; the full suite is unchanged at 8322.
…one definition (#741) `DecodedRecord`, `GroupKey`, `GroupKeyConfig`, `LibraryIndex`, `LibraryLookup`, `build_library_lookup`, and the `Grouper` trait each existed twice: once in `fgumi-bam-io` (ported in #734) and once in `unified_pipeline` / `read_info`. The copies were textually identical apart from field visibility and doc formatting, and the duplication was deliberate — #734 left the umbrella copies in place so nothing had to be rewired. That worked while the ported step library only ever *produced* these values. It stops working at the first ported step that hands one to an umbrella grouper: `GroupBam` calls `TemplateGrouper::add_records`, and the two identical definitions are two incompatible types, so the call cannot be written at all. Keep the `fgumi-bam-io` definition and re-export it from both former homes, so every existing `crate::unified_pipeline::DecodedRecord` and `crate::read_info::LibraryIndex` path resolves unchanged. Two supporting changes fall out: - `GroupKey::has_mate_position` only existed on the umbrella copy; ported to `fgumi-bam-io` so the surviving definition is a superset of both. - `grouper.rs` reached into `DecodedRecord`'s fields directly, which are private on the `fgumi-bam-io` copy (made so during #734's review). Those five sites now go through `into_raw_bytes` / `record` / `raw_bytes`, which is what the accessors are for. Net -483 lines with no behavior change; the full suite is unchanged at 8322.
Prerequisite for R1c. Discovered while porting
steps/group/, which is the first ported code that cannot be written without it.Why
#734 moved
DecodedRecord,GroupKey,GroupKeyConfig, and the library-lookup helpers intofgumi-bam-io, and deliberately left theunified_pipeline/read_infocopies in place so nothing had to be rewired. That was the right call at the time: the ported step library only ever produced these values, so two identical definitions coexisted harmlessly.steps/group/breaks the arrangement.GroupBamcallsTemplateGrouper::add_records, which isfgumi_bam_io::Grouperon one side and the umbrellaGrouperon the other — typed over two differentDecodedRecords:Two textually identical definitions are still two types. The call cannot be written until they are one.
What changed
Keep the
fgumi-bam-iodefinition; re-export it from both former homes so every existingcrate::unified_pipeline::DecodedRecordandcrate::read_info::LibraryIndexpath resolves unchanged. Collapsed:DecodedRecord,GroupKey,GroupKeyConfig,LibraryIndex,LibraryLookup,build_library_lookup,unknown_library, and theGroupertrait.Before removing each copy I diffed the two. All were identical apart from field visibility and doc-comment formatting; where they differed in API the
fgumi-bam-ioside was already a superset (GroupKeyConfig::name_hash_only,DecodedRecord::{record, raw_bytes_mut, cached_umi_position_opt},GroupKey::name_hash_only). One exception went the other way and was ported across:GroupKey::has_mate_positionexisted only on the umbrella copy, so it moved tofgumi-bam-io. The surviving definition is now a superset of both.grouper.rsreached intoDecodedRecord's fields directly. Those are private on thefgumi-bam-iocopy — made so during #734's review — so five sites now go throughinto_raw_bytes()/record()/raw_bytes()instead.Risk
No behavior change; this is deletion plus re-export. Net -483 lines. The suite is unchanged at 8322 passing, which is the main evidence: every caller of these types kept compiling and kept passing against a single definition.
The duplication ledger from the landing plan shrinks accordingly — R6 has this much less to unpick when
unified_pipelineis deleted.Gate
ci-fmt,ci-lint,ci-tag-literals,ci-doc(-D warnings),publish-crates.sh --check,ci-test— all exit 0.Risk: command output changes none;
unsafechanges none and theCLAUDE.mdallowlist is unchanged; memory bounds, queue capacities, and thread/backpressure policies change none.Fix: Consolidate grouping types in
fgumi-bam-ioand preserve existing import paths through re-exports.GroupBamandTemplateGrouper.GroupKey::has_mate_positionintofgumi-bam-io.DecodedRecordfield access with accessors.unknown_library()acrossReadInfofallbacks.