/v1/digitize: settings don't actually affect output #22

New issue

Closed

opened 2026-09-08 19:08:08 +00:00 by Mark · 1 comment

Mark commented

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

Owner

/v1/digitize: settings don't actually affect output

Repo: Mark/easystitch-service
Severity: High
Found: 2026-09-08 full shakedown

Symptom

POST /v1/digitize accepts a settings JSON object with min_stitch_length_mm,
max_stitch_length_mm, fill_density_mm, etc. — but changes to these values produce
identical stitch output.

tests/integration/test_digitize_e2e.py::test_digitize_settings_affect_output currently fails:
with min_stitch_length_mm=1.0 and =4.0, both responses return exactly 2032 stitches.

Where the engine itself DOES honor the setting

At the library level, EmbroideryPipeline.process(input_bytes=..., output_format=..., settings=...)
correctly varies stitch count by min_stitch_length_mm:

min_stitch_length_mm=1.0 -> 88 stitches
min_stitch_length_mm=4.0 -> 43 stitches
min_stitch_length_mm=8.0 -> 37 stitches

So the bug is in the service's translation or call path, not in the engine.

Likely location

easystitch-service/pipeline_runner.py — either _translate_settings() (line 374) is dropping
fields, or the call into pipeline.digitize_to_stitches(...) (line 614) isn't passing the
translated settings through to the engine's stitch-generation stage.

Acceptance

test_digitize_settings_affect_output passes
Manually: digitize the same fixture PNG with min_stitch_length_mm=1.0 vs 4.0 and confirm
the returned stats.totalStitches differs

## /v1/digitize: settings don't actually affect output **Repo:** Mark/easystitch-service **Severity:** High **Found:** 2026-09-08 full shakedown ### Symptom `POST /v1/digitize` accepts a `settings` JSON object with `min_stitch_length_mm`, `max_stitch_length_mm`, `fill_density_mm`, etc. — but changes to these values produce **identical stitch output**. `tests/integration/test_digitize_e2e.py::test_digitize_settings_affect_output` currently fails: with `min_stitch_length_mm=1.0` and `=4.0`, both responses return exactly 2032 stitches. ### Where the engine itself DOES honor the setting At the library level, `EmbroideryPipeline.process(input_bytes=..., output_format=..., settings=...)` correctly varies stitch count by `min_stitch_length_mm`: ``` min_stitch_length_mm=1.0 -> 88 stitches min_stitch_length_mm=4.0 -> 43 stitches min_stitch_length_mm=8.0 -> 37 stitches ``` So the bug is in the **service's translation or call path**, not in the engine. ### Likely location `easystitch-service/pipeline_runner.py` — either `_translate_settings()` (line 374) is dropping fields, or the call into `pipeline.digitize_to_stitches(...)` (line 614) isn't passing the translated settings through to the engine's stitch-generation stage. ### Acceptance - `test_digitize_settings_affect_output` passes - Manually: digitize the same fixture PNG with `min_stitch_length_mm=1.0` vs `4.0` and confirm the returned `stats.totalStitches` differs

Mark added the

bug

triage-approved

in-progress

labels

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

Mark commented

2026-09-08 21:50:24 +00:00

Author

Owner

Launcher block — stale claim on Mark/easystitch-service#22

The previous kilo-gsd.py run (orphaned task t_b8d24882) left a live process tree that any new dispatch must reap before retrying:

tmux kilo-gsd-easystitch-service-22 (created 14:35:17) — alive, idle
tmux kilo-gsd-easystitch-service-22-bugfix (created 14:49:03) — alive, idle (bugfix agent finished, ruff now passes)
orphan python pid 661885 — S+-sleeping, stdout/stderr still on the log
2 local commits ahead of origin/main referencing #22: 073e69b (mock-pipeline regression) and e9c29ac (lint fix). Not yet pushed.

The kanban launcher (t_8e57350e) is blocking with kind=capability. The watcher/janitor needs to: (1) tmux kill-session -t kilo-gsd-easystitch-service-22 and kilo-gsd-easystitch-service-22-bugfix, (2) kill 661885 if still present, (3) verify git push origin main from easystitch-service succeeds, (4) close this issue when the canonical commits land on origin.

No new kilo-gsd.py run was spawned — the idempotency check in kilo-gsd.py would no-op against the live tmux session anyway.

**Launcher block — stale claim on Mark/easystitch-service#22** The previous kilo-gsd.py run (orphaned task `t_b8d24882`) left a live process tree that any new dispatch must reap before retrying: - tmux `kilo-gsd-easystitch-service-22` (created 14:35:17) — alive, idle - tmux `kilo-gsd-easystitch-service-22-bugfix` (created 14:49:03) — alive, idle (bugfix agent finished, ruff now passes) - orphan python pid 661885 — S+-sleeping, stdout/stderr still on the log - 2 local commits ahead of origin/main referencing #22: `073e69b` (mock-pipeline regression) and `e9c29ac` (lint fix). Not yet pushed. The kanban launcher (t_8e57350e) is blocking with `kind=capability`. The watcher/janitor needs to: (1) `tmux kill-session -t kilo-gsd-easystitch-service-22` and `kilo-gsd-easystitch-service-22-bugfix`, (2) `kill 661885` if still present, (3) verify `git push origin main` from easystitch-service succeeds, (4) close this issue when the canonical commits land on origin. No new kilo-gsd.py run was spawned — the idempotency check in kilo-gsd.py would no-op against the live tmux session anyway.

Mark

2026-09-08 21:51:16 +00:00