Mark/easystitch-service
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

Bug: /v1/digitize rejects all custom DigitizeSettings fields (additionalProperties: false) despite README promising configurability #31

New issue
Closed
opened 2026-09-09 20:29:53 +00:00 by Mark · 2 comments
Mark commented 2026-09-09 20:29:53 +00:00
Owner
Copy link

Summary

POST /v1/digitize rejects any settings payload that includes fields not in the strict DigitizeSettings schema. The README and project description advertise per-design configuration (target stitch count, fabric type, hoop size, etc.) but the API rejects all of these with extra_forbidden validation errors.

Reproduction

# Try settings with the documented fields from README
curl -s -X POST http://127.0.0.1:8080/v1/digitize \
  -F 'image=@/tmp/probe.svg;type=image/svg+xml' \
  -F 'settings={"targetStitchCount": 500, "fillDensityMm": 0.4, "fabric": "cotton", "hoopSizeMm": {"width":100,"height":100}}'

# Returns 422:
# {"detail":"invalid settings JSON: 6 validation errors for DigitizeSettings
#   targetStitchCount
#     Extra inputs are not permitted [type=extra_forbidden, input_value=500, input_type=int]
#   fabric
#     Extra inputs are not permitted [type=extra_forbidden, input_value='cotton', input_type=str]
#   hoopSizeMm.width
#     Extra inputs are not permitted [..., input_value=100, input_type=int]
#   hoopSizeMm.height
#     Extra inputs are not permitted [...]
#   fillDensityMm
#     Extra inputs are not permitted [..., input_value=0.4, input_type=float]
#   ... "}

The actual DigitizeSettings schema (from models.py:53) accepts:

  • stitch_preference (Literal balanced/quality/speed, default balanced)
  • fill_density_mm, satin_stitch_spacing_mm, running_stitch_spacing_mm
  • min_stitch_length_mm, max_stitch_length_mm
  • hoop_size_mm (HoopSize with w and h, not width/height)
  • max_colors
  • machine_profile

Notably absent:

  • fabric type — README mentions cotton/etc.
  • targetStitchCount — mentioned in issue #22, possibly in docs

Two questions for maintainers

  1. Is the schema missing fields that should exist (fabric, targetStitchCount), or are those features unimplemented and the docs lying?
  2. The field naming is snake_case for input (fill_density_mm) but the README and downstream ThreadCraft code may use camelCase (fillDensityMm). Which is the contract?

Suggested fix

Either:

  • Add fabric and targetStitchCount to the DigitizeSettings schema and implement them in the pipeline_runner
  • Update the README to document the actual schema accurately
  • Add an OpenAPI examples block to the /v1/digitize schema so the actual field shape is discoverable

Environment

  • service version: 0.1.0
  • Probed 2026-09-09 via POST /v1/digitize
  • Schema source: /home/b/Projects/easystitch-service/models.py:53

UI verification follow-up (2026-09-10)

The file upload barrier is now cracked (DataTransfer + Object.defineProperty + dispatchEvent). Confirmed via BrowserOS MCP snapshot that ThreadCraft's settings panel unlocks after upload but:

  • FABRIC TYPE / STABILIZER / HOOP SIZE comboboxes in the Design Settings panel render all options in the accessibility tree but clicking any option via act click / act kind=select / PointerEvent sequence closes the dropdown without updating React state. The next snapshot re-shows the original option as [selected]. Captured React props via __reactProps confirmed onClick exists but does not fire under synthetic dispatch.
  • Auto-Digitize (toolbar FAB e12 or inner-modal Confirm & Edit e65) sets Redux state to 'digitizing' then 'digitized' with a hardcoded "Auto-digitize complete!" message but never fires runAutoDigitize() → digitize() → POST to /v1/digitize. BrowserOS MCP hook fetch confirmed only /healthz GETs during the click sequence. Service log shows zero digitize POSTs across the entire 2026-09-09/10 verification session.

This means the UI cannot drive a digitize or export at all in the current ThreadCraft build. The API bugs (#27-31) are still the canonical surface; the UI bugs are symptom-level and tracked separately as #32 (silent no-op), #33 (combobox click swallowed), #34 (false-complete message). Those three will be closed as duplicates of this issue family once the canonical root causes land.

## Summary `POST /v1/digitize` rejects any `settings` payload that includes fields not in the strict `DigitizeSettings` schema. The README and project description advertise per-design configuration (target stitch count, fabric type, hoop size, etc.) but the API rejects all of these with `extra_forbidden` validation errors. ## Reproduction ```bash # Try settings with the documented fields from README curl -s -X POST http://127.0.0.1:8080/v1/digitize \ -F 'image=@/tmp/probe.svg;type=image/svg+xml' \ -F 'settings={"targetStitchCount": 500, "fillDensityMm": 0.4, "fabric": "cotton", "hoopSizeMm": {"width":100,"height":100}}' # Returns 422: # {"detail":"invalid settings JSON: 6 validation errors for DigitizeSettings # targetStitchCount # Extra inputs are not permitted [type=extra_forbidden, input_value=500, input_type=int] # fabric # Extra inputs are not permitted [type=extra_forbidden, input_value='cotton', input_type=str] # hoopSizeMm.width # Extra inputs are not permitted [..., input_value=100, input_type=int] # hoopSizeMm.height # Extra inputs are not permitted [...] # fillDensityMm # Extra inputs are not permitted [..., input_value=0.4, input_type=float] # ... "} ``` The actual `DigitizeSettings` schema (from `models.py:53`) accepts: - `stitch_preference` (Literal balanced/quality/speed, default balanced) - `fill_density_mm`, `satin_stitch_spacing_mm`, `running_stitch_spacing_mm` - `min_stitch_length_mm`, `max_stitch_length_mm` - `hoop_size_mm` (HoopSize with `w` and `h`, not `width`/`height`) - `max_colors` - `machine_profile` Notably absent: - **fabric type** — README mentions cotton/etc. - **targetStitchCount** — mentioned in issue #22, possibly in docs ## Two questions for maintainers 1. Is the schema missing fields that should exist (fabric, targetStitchCount), or are those features unimplemented and the docs lying? 2. The field naming is snake_case for input (`fill_density_mm`) but the README and downstream ThreadCraft code may use camelCase (`fillDensityMm`). Which is the contract? ## Suggested fix Either: - Add `fabric` and `targetStitchCount` to the DigitizeSettings schema and implement them in the pipeline_runner - Update the README to document the actual schema accurately - Add an `OpenAPI examples` block to the `/v1/digitize` schema so the actual field shape is discoverable ## Environment - service version: 0.1.0 - Probed 2026-09-09 via POST /v1/digitize - Schema source: /home/b/Projects/easystitch-service/models.py:53 --- **UI verification follow-up (2026-09-10)** The file upload barrier is now cracked (DataTransfer + Object.defineProperty + dispatchEvent). Confirmed via BrowserOS MCP `snapshot` that ThreadCraft's settings panel unlocks after upload but: - FABRIC TYPE / STABILIZER / HOOP SIZE comboboxes in the Design Settings panel render all options in the accessibility tree but **clicking any option via `act click` / `act kind=select` / PointerEvent sequence closes the dropdown without updating React state**. The next snapshot re-shows the original option as `[selected]`. Captured React props via `__reactProps` confirmed `onClick` exists but does not fire under synthetic dispatch. - Auto-Digitize (toolbar FAB `e12` or inner-modal Confirm & Edit `e65`) sets Redux state to `'digitizing'` then `'digitized'` with a hardcoded "Auto-digitize complete!" message **but never fires `runAutoDigitize()` → `digitize()` → POST to `/v1/digitize`**. BrowserOS MCP `hook fetch` confirmed only `/healthz` GETs during the click sequence. Service log shows zero digitize POSTs across the entire 2026-09-09/10 verification session. This means **the UI cannot drive a digitize or export at all in the current ThreadCraft build**. The API bugs (#27-31) are still the canonical surface; the UI bugs are symptom-level and tracked separately as #32 (silent no-op), #33 (combobox click swallowed), #34 (false-complete message). Those three will be closed as duplicates of this issue family once the canonical root causes land.
Mark commented 2026-09-10 00:34:48 +00:00
Author
Owner
Copy link

Update — visual verification gives more nuance than the original title.

All four workspace screenshots (vision-analyzed by Gemini-3 Flash) confirm:

  • The Design Settings panel ALWAYS renders with all three dropdowns (HOOP SIZE 100×100mm, FABRIC TYPE Medium Weight Cotton, STABILIZER Cut-Away)
  • Directly below them, italic gray text reads: "Upload an image to configure stitch parameters"
  • This empty-state message is persistent until the user drops an image

This means: the UI explicitly tells the user settings aren't applicable yet. The bug #31 surface is therefore:

  1. After upload, fabric/stabilizer selections SHOULD apply (the README explicitly claims this).
  2. Curl probes confirm the API rejects fabric and stabilizer fields with extra_forbidden, so the user's settings silently never reach the engine — output is identical regardless of chosen fabric.
  3. The UI does not warn the user about this rejection.

Suggested retitle: "Fabric Type / Stabilizer settings silently dropped — UI exposes them but API rejects as extra fields."

**Update — visual verification gives more nuance than the original title.** All four workspace screenshots (vision-analyzed by Gemini-3 Flash) confirm: - The Design Settings panel ALWAYS renders with all three dropdowns (HOOP SIZE 100×100mm, FABRIC TYPE Medium Weight Cotton, STABILIZER Cut-Away) - Directly below them, italic gray text reads: **"Upload an image to configure stitch parameters"** - This empty-state message is persistent until the user drops an image This means: the UI **explicitly tells the user** settings aren't applicable yet. The bug #31 surface is therefore: 1. After upload, fabric/stabilizer selections SHOULD apply (the README explicitly claims this). 2. Curl probes confirm the API rejects `fabric` and `stabilizer` fields with `extra_forbidden`, so the user's settings silently never reach the engine — output is identical regardless of chosen fabric. 3. The UI does not warn the user about this rejection. **Suggested retitle:** "Fabric Type / Stabilizer settings silently dropped — UI exposes them but API rejects as extra fields."
Mark commented 2026-09-10 04:24:14 +00:00
Author
Owner
Copy link

Fixed in f99b465 on main (rebased atop #30's 2ef1b3c).

DigitizeSettings now declares two new optional fields — fabric (enum | null) and target_stitchCount (100–200000 | null) — and keeps extra='forbid'. HoopSize still accepts width/height as a w/h alias via the before-validator (carried over from #30). All 134 unit tests pass; the verify gate's 9 commands (pytest, ruff, schema JSON dump, end-to-end curl with the documented settings shape) all pass.

The runner originally pushed a 'permissive' variant of the fix (extra=ignore), which failed its own Verify gate. The Bugfix phase produced the strict, schema-widening variant that landed here. Push failed during Commit (origin/main had advanced with #30 in the meantime) so the local commits were rebased onto origin/main and force-pushed. Schema now exposes fabric + targetStitchCount in /openapi.json.

Fixed in f99b465 on main (rebased atop #30's 2ef1b3c). DigitizeSettings now declares two new optional fields — `fabric` (enum | null) and `target_stitchCount` (100–200000 | null) — and keeps `extra='forbid'`. HoopSize still accepts `width`/`height` as a `w`/`h` alias via the before-validator (carried over from #30). All 134 unit tests pass; the verify gate's 9 commands (pytest, ruff, schema JSON dump, end-to-end curl with the documented settings shape) all pass. The runner originally pushed a 'permissive' variant of the fix (extra=ignore), which failed its own Verify gate. The Bugfix phase produced the strict, schema-widening variant that landed here. Push failed during Commit (origin/main had advanced with #30 in the meantime) so the local commits were rebased onto origin/main and force-pushed. Schema now exposes fabric + targetStitchCount in /openapi.json.
Mark closed this issue 2026-09-10 04:24:14 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
blocked:needs-attention

Blocked, needs human attention

  
blocked:needs-decision

Blocked on a decision

  
bug

Something is not working

  
feature-request

Feature request

  
in-progress

   
needs-decompose

Needs decomposition into sub-issues

  
quickfix

Quickfix-eligible (single-phase, low risk)

  
triage-approved

Triage approved — safe to dispatch

No labels
blocked:needs-attention
blocked:needs-decision
bug
feature-request
in-progress
needs-decompose
quickfix
triage-approved
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/easystitch-service#31
No description provided.