EmbroideryPipeline.stages dict is never populated — no way to introspect pipeline progress #35

New issue

Closed

opened 2026-06-22 16:23:19 +00:00 by Mark · 1 comment

Mark commented

2026-06-22 16:23:19 +00:00

Owner

Bug

EmbroideryPipeline.__init__() constructs the four orchestrator components
(raster_converter, semantic_analyzer, dom_resolver, physical_optimizer)
but never populates self.stages with the PipelineStage instances. The
PipelineStage objects are created lazily inside process() and never
attached to the pipeline.

Reproduction

from main_pipeline import EmbroideryPipeline
p = EmbroideryPipeline()
print(p.stages)  # {} — empty

After a process() call, p.stages is still {} because the local
PipelineStage instances are never assigned to self.stages[...].

Impact

The HTTP service can't report "raster_to_vector: 12ms, semantic_analysis:
87ms, ..." timings back to the client.
The CLI's verbose mode has no way to print stage timings.
Tests can't assert on per-stage behavior without re-deriving it from
scratch.
Debugging slow pipelines requires reading logs, not introspecting state.

Fix

In process(), after creating each PipelineStage, register it:
self.stages[stage.name] = stage.

Also fix the docstring on __init__ to document self.stages as a
publicly-readable dict.

Acceptance

After process() returns, p.stages is a dict with one entry per stage.
Each entry has name, description, start_time, end_time, duration.
HTTP service /v1/digitize response includes a stages breakdown.
CLI verbose mode prints per-stage timings.

## Bug `EmbroideryPipeline.__init__()` constructs the four orchestrator components (`raster_converter`, `semantic_analyzer`, `dom_resolver`, `physical_optimizer`) but never populates `self.stages` with the `PipelineStage` instances. The `PipelineStage` objects are created lazily inside `process()` and never attached to the pipeline. ## Reproduction ```python from main_pipeline import EmbroideryPipeline p = EmbroideryPipeline() print(p.stages) # {} — empty ``` After a `process()` call, `p.stages` is still `{}` because the local `PipelineStage` instances are never assigned to `self.stages[...]`. ## Impact - The HTTP service can't report "raster_to_vector: 12ms, semantic_analysis: 87ms, ..." timings back to the client. - The CLI's verbose mode has no way to print stage timings. - Tests can't assert on per-stage behavior without re-deriving it from scratch. - Debugging slow pipelines requires reading logs, not introspecting state. ## Fix In `process()`, after creating each `PipelineStage`, register it: `self.stages[stage.name] = stage`. Also fix the docstring on `__init__` to document `self.stages` as a publicly-readable dict. ## Acceptance - After `process()` returns, `p.stages` is a dict with one entry per stage. - Each entry has `name`, `description`, `start_time`, `end_time`, `duration`. - HTTP service `/v1/digitize` response includes a `stages` breakdown. - CLI verbose mode prints per-stage timings.