Context
The end-to-end mapping pipeline is implemented twice:
src/dcd_mapping/main.py::map_scoreset — CLI flow (console progress via _emit_info, writes output JSON to disk via save_mapped_output_json).src/api/routers/map.py::map_scoreset — FastAPI route (returns a ScoresetMapping JSONResponse; this is what the mavedb-api worker calls).
Both inline the same stage sequence:
metadata/records → build_alignment_result → select_transcripts → vrs_map (per target) → annotate (per target) → cross-level translation + build_mapping_records → compute_target_gene_info + build_scoreset_mapping
Error handling differs (CLI logs and writes an error JSON then returns; the route returns an error-bearing ScoresetMapping or raises HTTPException), but the core orchestration is duplicated line-for-line.
Problem
Every pipeline change must be applied in both places or the two flows silently drift. This already surfaced during the Better Reverse Translation work (dcd_mapping2#100): the new cross-level translation + MappingRecord/Allele draft stage had to be added to each flow separately.
Proposed fix
Extract the shared orchestration into a single function (e.g. map_scoreset_core(...) -> ScoresetMapping) that runs the stage sequence and returns the assembled ScoresetMapping (including the error-message-only form on failure). The two entry points become thin adapters:
- CLI: wraps the core with
_emit_info progress logging and write_scoreset_mapping_to_json.
- API route: wraps the core with HTTP error translation and
JSONResponse.
Behavior-preserving; no change to mapper output schema.
Acceptance criteria
- Single shared orchestration function; both
main.py::map_scoreset and api/routers/map.py::map_scoreset delegate to it.
- CLI behavior unchanged (progress output, JSON file writing, return/exit semantics).
- API route behavior unchanged (status codes,
error_message responses, response_model).
- Existing tests pass; add coverage for the shared function.
Related: dcd_mapping2#100, mavedb-api#746.
Context
The end-to-end mapping pipeline is implemented twice:
src/dcd_mapping/main.py::map_scoreset— CLI flow (console progress via_emit_info, writes output JSON to disk viasave_mapped_output_json).src/api/routers/map.py::map_scoreset— FastAPI route (returns aScoresetMappingJSONResponse; this is what the mavedb-api worker calls).Both inline the same stage sequence:
metadata/records → build_alignment_result → select_transcripts → vrs_map (per target) → annotate (per target) → cross-level translation + build_mapping_records → compute_target_gene_info + build_scoreset_mappingError handling differs (CLI logs and writes an error JSON then returns; the route returns an error-bearing
ScoresetMappingor raisesHTTPException), but the core orchestration is duplicated line-for-line.Problem
Every pipeline change must be applied in both places or the two flows silently drift. This already surfaced during the Better Reverse Translation work (dcd_mapping2#100): the new cross-level translation +
MappingRecord/Alleledraft stage had to be added to each flow separately.Proposed fix
Extract the shared orchestration into a single function (e.g.
map_scoreset_core(...) -> ScoresetMapping) that runs the stage sequence and returns the assembledScoresetMapping(including the error-message-only form on failure). The two entry points become thin adapters:_emit_infoprogress logging andwrite_scoreset_mapping_to_json.JSONResponse.Behavior-preserving; no change to mapper output schema.
Acceptance criteria
main.py::map_scoresetandapi/routers/map.py::map_scoresetdelegate to it.error_messageresponses,response_model).Related: dcd_mapping2#100, mavedb-api#746.