statistics.total_stitches always reports 0 from EmbroideryPipeline #125

New issue

Closed

opened 2026-09-08 19:08:10 +00:00 by Mark · 0 comments

Mark commented

2026-09-08 19:08:10 +00:00

Owner

statistics.total_stitches always reports 0 from EmbroideryPipeline

Repo: Mark/easystitch
Severity: Medium — every library consumer sees wrong metric
Found: 2026-09-08 full shakedown

Symptom

EmbroideryPipeline.process(...).statistics.total_stitches is always 0, regardless of how
many stitches are actually emitted. Verified across 5 fixtures:

Fixture	Engine total_stitches	pyembroidery read-back
`data/sample.svg`	0	185
`data/test_fixtures/mixed_stitches.svg`	0	88
`data/test_fixtures/simple_square.png`	0	4222
`data/sample_vis.png` (2510x2562)	0	(24MB DST)

Same for estimated_stitch_count on each StitchIntent — always 0.

Why it's partially masked in production

easystitch-service/pipeline_runner.py:629 recomputes total_stitches from grouped stitch
objects after the pipeline runs, so the HTTP API returns correct counts. But every other
consumer of the engine library (CLI tools, notebooks, future integrations) gets the wrong metric.

Likely location

src/main_pipeline.py — somewhere in the stage where statistics is built; populated from the
wrong source (pre-emission estimates that are never updated).

Acceptance

process(...).statistics.total_stitches matches actual stitch count (verifiable via pyembroidery)
stitch_intents[*].estimated_stitch_count is a real estimate, not always 0
Service tests still pass (their assertions go through the recomputed path)

## statistics.total_stitches always reports 0 from EmbroideryPipeline **Repo:** Mark/easystitch **Severity:** Medium — every library consumer sees wrong metric **Found:** 2026-09-08 full shakedown ### Symptom `EmbroideryPipeline.process(...).statistics.total_stitches` is **always 0**, regardless of how many stitches are actually emitted. Verified across 5 fixtures: | Fixture | Engine total_stitches | pyembroidery read-back | |---|---|---| | `data/sample.svg` | 0 | 185 | | `data/test_fixtures/mixed_stitches.svg` | 0 | 88 | | `data/test_fixtures/simple_square.png` | 0 | 4222 | | `data/sample_vis.png` (2510x2562) | 0 | (24MB DST) | Same for `estimated_stitch_count` on each `StitchIntent` — always 0. ### Why it's partially masked in production `easystitch-service/pipeline_runner.py:629` recomputes `total_stitches` from grouped stitch objects after the pipeline runs, so the HTTP API returns correct counts. But every other consumer of the engine library (CLI tools, notebooks, future integrations) gets the wrong metric. ### Likely location `src/main_pipeline.py` — somewhere in the stage where `statistics` is built; populated from the wrong source (pre-emission estimates that are never updated). ### Acceptance - `process(...).statistics.total_stitches` matches actual stitch count (verifiable via pyembroidery) - `stitch_intents[*].estimated_stitch_count` is a real estimate, not always 0 - Service tests still pass (their assertions go through the recomputed path)