Comboboxes (HOOP/FABRIC/STABILIZER) display defaults after Auto-Digitize completes #64

New issue

Closed

opened 2026-09-10 17:56:27 +00:00 by Mark · 1 comment

Mark commented

2026-09-10 17:56:27 +00:00

Owner

Comboboxes (HOOP/FABRIC/STABILIZER) display defaults after Auto-Digitize completes

Repo: Mark/Kimi_Agent_Brother_10_Digitizing_App
Severity: High — likely regresses Mark/easystitch-service#22 (settings not affecting output)
Found: 2026-09-10, webui usability shakedown

Problem

In the Workspace right panel, the Hoop Size / Fabric Type / Stabilizer comboboxes show
the default values (100×100mm / Medium Weight Cotton / Cut-Away) immediately after
Auto-Digitize completes — even when non-default values were selected before clicking
"Run Auto-Digitize".

Two possibilities; both are bugs:

Display bug (cosmetic): state.appliedSettings is correctly threaded to
toServiceSettings, the digitize used the non-default values, but the combobox
value bindings reset on state transition (image-uploaded → digitizing →
digitized).
Functional bug (regression risk): the combobox state itself was reset, so the
digitize actually used the defaults and the user's selections were silently dropped.

Either way the user sees: "I picked Stretchy Knit, but after digitize the combobox
shows Medium Cotton, and the export I got back looks like it was made with Medium
Cotton settings." That is the exact failure mode that Mark/easystitch-service#22 was
supposed to fix on the backend. We need to know which side is broken.

Reproduction

pnpm dev (Vite :5173 → service :8080).
Navigate to /workspace, upload simple_square.png (or any image).
Change Hoop Size to 200×300mm (8×12), Fabric to Stretchy / Knit,
Stabilizer to Tear-Away.
Click "Run Auto-Digitize".
Wait for completion toast.
Observe the three comboboxes — they all show their default values again.

How to distinguish display-bug vs functional-bug

Capture network traffic during step 4. The POST to /api/easystitch/v1/digitize
body's DigitizeSettings payload should include hoopSize: { width: 200, height: 300 }
or equivalent. If the payload matches what was selected, it's a display bug. If the
payload shows the defaults, it's a functional bug and the fix needs to land in
useWorkspace.ts toServiceSettings call.

Suggested fix

After SET_STATE: 'digitized', re-read state.designSettings.hoopSize,
state.designSettings.fabric, state.designSettings.stabilizer and bind the
combobox value props to those, not to a transient local state.
Add a vitest regression test that asserts the combobox value persists across the
image-uploaded → digitizing → digitized state transitions.

Acceptance

After Auto-Digitize completes, the three comboboxes still reflect the values the
user selected before clicking Run.
The DigitizeSettings payload sent to the service matches what the user selected.
A unit test covers the round-trip.

## Comboboxes (HOOP/FABRIC/STABILIZER) display defaults after Auto-Digitize completes **Repo:** Mark/Kimi_Agent_Brother_10_Digitizing_App **Severity:** High — likely regresses Mark/easystitch-service#22 (settings not affecting output) **Found:** 2026-09-10, webui usability shakedown ## Problem In the Workspace right panel, the Hoop Size / Fabric Type / Stabilizer comboboxes show the **default** values (100×100mm / Medium Weight Cotton / Cut-Away) immediately after Auto-Digitize completes — even when non-default values were selected before clicking "Run Auto-Digitize". Two possibilities; both are bugs: 1. **Display bug (cosmetic):** state.appliedSettings is correctly threaded to `toServiceSettings`, the digitize used the non-default values, but the combobox `value` bindings reset on state transition (`image-uploaded` → `digitizing` → `digitized`). 2. **Functional bug (regression risk):** the combobox state itself was reset, so the digitize actually used the defaults and the user's selections were silently dropped. Either way the user sees: "I picked Stretchy Knit, but after digitize the combobox shows Medium Cotton, and the export I got back looks like it was made with Medium Cotton settings." That is the exact failure mode that Mark/easystitch-service#22 was supposed to fix on the backend. We need to know which side is broken. ## Reproduction 1. `pnpm dev` (Vite :5173 → service :8080). 2. Navigate to `/workspace`, upload `simple_square.png` (or any image). 3. Change Hoop Size to `200×300mm (8×12)`, Fabric to `Stretchy / Knit`, Stabilizer to `Tear-Away`. 4. Click "Run Auto-Digitize". 5. Wait for completion toast. 6. Observe the three comboboxes — they all show their default values again. ## How to distinguish display-bug vs functional-bug Capture network traffic during step 4. The POST to `/api/easystitch/v1/digitize` body's `DigitizeSettings` payload should include `hoopSize: { width: 200, height: 300 }` or equivalent. If the payload matches what was selected, it's a display bug. If the payload shows the defaults, it's a functional bug and the fix needs to land in `useWorkspace.ts` `toServiceSettings` call. ## Suggested fix - After `SET_STATE: 'digitized'`, re-read `state.designSettings.hoopSize`, `state.designSettings.fabric`, `state.designSettings.stabilizer` and bind the combobox `value` props to those, not to a transient local state. - Add a vitest regression test that asserts the combobox value persists across the `image-uploaded → digitizing → digitized` state transitions. ## Acceptance - After Auto-Digitize completes, the three comboboxes still reflect the values the user selected before clicking Run. - The `DigitizeSettings` payload sent to the service matches what the user selected. - A unit test covers the round-trip.