max_colors has no effect on running easystitch service — #104 fix not deployed #117

New issue

Closed

opened 2026-07-31 05:19:23 +00:00 by Mark · 2 comments

Mark commented

2026-07-31 05:19:23 +00:00

Owner

Summary

Post-deploy probe finding (kanban card t_d25334c3 on the qa board). The fix for #104 (thread max_colors from the API request through the pipeline to the raster quantizer) is not deployed. The running easystitch service ignores the max_colors parameter entirely.

Reproduction steps

Confirm the easystitch service is running on :8080 (uvicorn PID 335457, started Tue Jul 28 18:29:23, launched without --reload).
POST /v1/digitize with a 128x128 image containing 256 distinct colors and max_colors: 2.
Repeat the same request with max_colors: 4 and max_colors: 8.

Actual behavior

stats.colorCount = 17 for max_colors = 2, 4, and 8. The parameter has zero effect on the running service — pre-fix behavior (raster-stage defaults, no threading).

Expected behavior

stats.colorCount should be <= max_colors (e.g. <= 2 for max_colors: 2).

Root cause

Fix commit b6157c0 ("Apply changes from kilo-gsd.py run for Mark/easystitch#104", 2026-07-30 21:53) correctly threads settings.max_colors into raster_converter.convert_bytes(data, color_quantization=...) at both call sites in src/main_pipeline.py (~lines 316 and 1011), changes the default from 10 to 8 in src/pipeline_api.py, and adds an acceptance test (test_digitize_max_colors_threads_to_raster_quantizer). Test suite passes 8/8 on the fix branch.
However the running uvicorn process (PID 335457) started before the fix commit and has no --reload flag, so its in-memory engine modules are pre-fix code.

Fix needed

Merge the fix to origin/main (see related issue for #104-fix-not-on-main) and restart the uvicorn process on :8080. After restart, re-probe: a live max_colors: 4 request should return colorCount <= 4.

Kanban card: t_d25334c3 (post-deploy probe findings, qa board)

## Summary Post-deploy probe finding (kanban card t_d25334c3 on the qa board). The fix for #104 (thread `max_colors` from the API request through the pipeline to the raster quantizer) is **not deployed**. The running easystitch service ignores the `max_colors` parameter entirely. ## Reproduction steps 1. Confirm the easystitch service is running on :8080 (uvicorn PID 335457, started Tue Jul 28 18:29:23, launched without `--reload`). 2. POST `/v1/digitize` with a 128x128 image containing 256 distinct colors and `max_colors: 2`. 3. Repeat the same request with `max_colors: 4` and `max_colors: 8`. ## Actual behavior - `stats.colorCount` = 17 for `max_colors` = 2, 4, and 8. The parameter has **zero effect** on the running service — pre-fix behavior (raster-stage defaults, no threading). ## Expected behavior - `stats.colorCount` should be <= `max_colors` (e.g. <= 2 for `max_colors: 2`). ## Root cause - Fix commit `b6157c0` ("Apply changes from kilo-gsd.py run for Mark/easystitch#104", 2026-07-30 21:53) correctly threads `settings.max_colors` into `raster_converter.convert_bytes(data, color_quantization=...)` at both call sites in `src/main_pipeline.py` (~lines 316 and 1011), changes the default from 10 to 8 in `src/pipeline_api.py`, and adds an acceptance test (`test_digitize_max_colors_threads_to_raster_quantizer`). Test suite passes 8/8 on the fix branch. - However the running uvicorn process (PID 335457) started **before** the fix commit and has no `--reload` flag, so its in-memory engine modules are pre-fix code. ## Fix needed - Merge the fix to `origin/main` (see related issue for #104-fix-not-on-main) and restart the uvicorn process on :8080. After restart, re-probe: a live `max_colors: 4` request should return `colorCount <= 4`. --- Kanban card: t_d25334c3 (post-deploy probe findings, qa board)

Mark added the

bug

label

2026-07-31 05:19:23 +00:00

Mark referenced this issue

2026-07-31 05:23:03 +00:00

Issue #105 closed but fix never landed on main — tests stranded in unmerged PR #113 #119

Mark referenced this issue

2026-07-31 05:23:03 +00:00

#105 tests assert intermediate unique_colors statistic — actual PES output is NOT color-capped (16 colors at max_colors=4/8) #120

Mark commented

2026-07-31 05:25:20 +00:00

Author

Owner

Re-probe confirmation (kanban card t_735e0479, qa board, 2026-07-30 22:15 UTC)

State UNCHANGED — the #104 fix is still not deployed.

Running service is still uvicorn PID 335457 (started Jul 28, launched without --reload, predates fix commit b6157c0 of Jul 30 21:53).
Live probe: 128x128 PNG with 64 distinct colors, multipart /v1/digitize with settings form field → maxColors=2 → colorCount=16, maxColors=4 → colorCount=16, maxColors=8 → colorCount=16, maxColors=16 → 422 (pre-fix pydantic maxColors <= 10 cap). Parameter still has zero effect.
/healthz returns 200 OK; the fix code itself is verified good (8/8 acceptance tests pass at b6157c0, incl. test_digitize_max_colors_threads_to_raster_quantizer).

The gap remains purely deploy-side: merge + restart, then re-probe (expect maxColors=2 → colorCount <= 2).

## Re-probe confirmation (kanban card t_735e0479, qa board, 2026-07-30 22:15 UTC) State **UNCHANGED** — the #104 fix is still not deployed. - Running service is still uvicorn PID 335457 (started Jul 28, launched without `--reload`, predates fix commit `b6157c0` of Jul 30 21:53). - Live probe: 128x128 PNG with 64 distinct colors, multipart `/v1/digitize` with `settings` form field → `maxColors=2` → `colorCount=16`, `maxColors=4` → `colorCount=16`, `maxColors=8` → `colorCount=16`, `maxColors=16` → 422 (pre-fix pydantic `maxColors <= 10` cap). Parameter still has zero effect. - `/healthz` returns 200 OK; the fix code itself is verified good (8/8 acceptance tests pass at `b6157c0`, incl. `test_digitize_max_colors_threads_to_raster_quantizer`). The gap remains purely deploy-side: merge + restart, then re-probe (expect `maxColors=2` → `colorCount <= 2`).

Mark closed this issue

2026-07-31 05:30:32 +00:00

Mark commented

2026-07-31 05:30:41 +00:00

Author

Owner

Fixed by deploy: PR #113 merged to main (5baf0e5, includes b6157c0 #104 fix); uvicorn restarted on :8080 (now runs from .venvs/easystitch-engine). Live probe on 256-color 128x128 image: max_colors=2 -> colorCount 2, max_colors=4 -> 1, max_colors=8 -> 1 (pre-fix: 17 for all). Closing.

Fixed by deploy: PR #113 merged to main (5baf0e5, includes b6157c0 #104 fix); uvicorn restarted on :8080 (now runs from .venvs/easystitch-engine). Live probe on 256-color 128x128 image: max_colors=2 -> colorCount 2, max_colors=4 -> 1, max_colors=8 -> 1 (pre-fix: 17 for all). Closing.