Progress callback wiring #91

New issue

Closed

opened 2026-06-26 21:37:52 +00:00 by Mark · 0 comments

Mark commented

2026-06-26 21:37:52 +00:00

Owner

Phase 1: Progress callback wiring

If P1 chose progress_cb, implement the per-stage progress
notifications. If P1 chose run_in_executor-only, this phase is
unnecessary (mark as N/A in the issue tracker).

Files:

Modify: src/main_pipeline.py (add progress_cb parameter, call
between stages)
Modify: src/service/handlers/digitize.py (forward progress events
to SSE response)
New: tests/test_progress_callback.py (asserts callback fires
for each stage, with correct stage names)

Acceptance:

Calling process(progress_cb=cb) invokes cb once per stage
transition with {stage, status, duration_ms?}.
The service handler emits SSE events that the ThreadCraft client
can render as a progress bar.
A test asserts the callback fires for the 5 stages in order:
raster_to_vector, semantic_annotation, dom_resolution,
physical_optimization, format_emission.

Depends on: P1 (decision), P2 (chosen primitive).

Out of scope

The actual thread-pool sizing / queue depth / timeout values are
covered by issue #43 (concurrency contract). This ticket is about
the API shape, not the operational parameters.
The progress_cb is for stage-level progress, not pixel-level
progress within a stage. That would require deeper refactoring
per stage.

Decomposed from easystitch#34

Decomposed from easystitch#53

## Phase 1: Progress callback wiring If P1 chose `progress_cb`, implement the per-stage progress notifications. If P1 chose `run_in_executor`-only, this phase is unnecessary (mark as N/A in the issue tracker). **Files:** - Modify: `src/main_pipeline.py` (add `progress_cb` parameter, call between stages) - Modify: `src/service/handlers/digitize.py` (forward progress events to SSE response) - New: `tests/test_progress_callback.py` (asserts callback fires for each stage, with correct stage names) **Acceptance:** - Calling `process(progress_cb=cb)` invokes `cb` once per stage transition with `{stage, status, duration_ms?}`. - The service handler emits SSE events that the ThreadCraft client can render as a progress bar. - A test asserts the callback fires for the 5 stages in order: `raster_to_vector`, `semantic_annotation`, `dom_resolution`, `physical_optimization`, `format_emission`. **Depends on:** P1 (decision), P2 (chosen primitive). ## Out of scope - The actual thread-pool sizing / queue depth / timeout values are covered by issue #43 (concurrency contract). This ticket is about the API shape, not the operational parameters. - The `progress_cb` is for stage-level progress, not pixel-level progress within a stage. That would require deeper refactoring per stage. --- _Decomposed from [easystitch#34](https://forgejo.tail018ac4.ts.net/Mark/easystitch/issues/34)_ --- _Decomposed from [easystitch#53](https://forgejo.tail018ac4.ts.net/Mark/easystitch/issues/53)_