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

Inner Auto-Digitize modal 'Confirm & Edit' button shows success message without API call #34

New issue
Closed
opened 2026-09-10 02:34:22 +00:00 by Mark · 3 comments
Mark commented 2026-09-10 02:34:22 +00:00
Owner
Copy link

Summary

After clicking the inner modal "Confirm & Edit" button (ref e65) in the Auto-Digitize preview modal, the UI updates with "Auto-digitize complete! Design ready for editing" but no /v1/digitize request is ever sent. The "complete" message is a hardcoded UI string that fires unconditionally on the click handler, regardless of whether any network work happened.

Reproduction

  1. Upload an image.
  2. Click Auto-Digitize FAB (toolbar e12) or Design Settings Auto-Digitize (e48).
  3. Auto-Digitize inner modal opens with Image/Stitches/Both preview toggles (refs e61/e62/e63) and a Confirm & Edit button (ref e65).
  4. Click Confirm & Edit.
  5. UI updates: "Auto-digitize complete! Design ready for editing."
  6. Service log shows zero POSTs to /v1/digitize during this sequence.

Code path

Likely RightPanel.tsx:217:

onClick={() => {
  dispatch({ type: 'SET_STATE', state: 'digitizing' });
  dispatch({ type: 'SET_PROCESSING', step: 0, message: 'Detecting color regions...' });
}}

Then a separate dispatch flips to 'digitized' and shows the toast. The actual digitize() call from useWorkspace.ts:432 is never triggered in this flow — the modal's Confirm & Edit is just a state transition.

Expected behavior

The "Confirm & Edit" should fire runAutoDigitize() (the actual API-calling handler) before transitioning to 'digitized'. Or the message should be reworded to "Preview generated" so users don't think the digitize completed.

Severity: high — same family as #32 (silent no-op on Auto-Digitize). User confusion guaranteed.

**Summary** After clicking the inner modal "Confirm & Edit" button (ref `e65`) in the Auto-Digitize preview modal, the UI updates with "Auto-digitize complete! Design ready for editing" **but no `/v1/digitize` request is ever sent**. The "complete" message is a hardcoded UI string that fires unconditionally on the click handler, regardless of whether any network work happened. **Reproduction** 1. Upload an image. 2. Click Auto-Digitize FAB (toolbar `e12`) or Design Settings Auto-Digitize (`e48`). 3. Auto-Digitize inner modal opens with Image/Stitches/Both preview toggles (refs `e61/e62/e63`) and a Confirm & Edit button (ref `e65`). 4. Click Confirm & Edit. 5. UI updates: "Auto-digitize complete! Design ready for editing." 6. **Service log shows zero POSTs to `/v1/digitize` during this sequence.** **Code path** Likely `RightPanel.tsx:217`: ```tsx onClick={() => { dispatch({ type: 'SET_STATE', state: 'digitizing' }); dispatch({ type: 'SET_PROCESSING', step: 0, message: 'Detecting color regions...' }); }} ``` Then a separate dispatch flips to `'digitized'` and shows the toast. The actual `digitize()` call from `useWorkspace.ts:432` is never triggered in this flow — the modal's `Confirm & Edit` is just a state transition. **Expected behavior** The "Confirm & Edit" should fire `runAutoDigitize()` (the actual API-calling handler) before transitioning to `'digitized'`. Or the message should be reworded to "Preview generated" so users don't think the digitize completed. **Severity**: high — same family as #32 (silent no-op on Auto-Digitize). User confusion guaranteed.
Mark commented 2026-09-10 02:53:59 +00:00
Author
Owner
Copy link

Closed as duplicate of the original API-contract bugs filed earlier in this thread (#27, #28, #29, #30, #31 on Mark/easystitch-service).

This issue describes a UI symptom of a deeper family of bugs. The UI cannot drive the digitize/export flow end-to-end because:

  1. #32 (silent no-op) — root cause is useWorkspace.ts:414-432 bailing silently when state.uploadedImage is null, plus RightPanel.tsx:217 showing a hardcoded "complete!" message without ever firing the API call. The actual API contract bugs are in the service layer (#27, #28, #30, #31) — fix the server contract first, then the UI flow becomes verifiable.

  2. #33 (combobox click swallowed) — root cause is a custom Radix-like dropdown wrapper in RightPanel.tsx that doesn't fire React onChange on synthetic events. The settings panel exists but is functionally inert; the only working path is the API directly. The user-facing impact is #31 (DigitizeSettings rejects fabric/stabilizer) — the user CAN'T set fabric/stabilizer through the UI at all, so the API's extra_forbidden rejection is moot until the UI is fixed separately.

  3. #34 (false-complete message) — same root cause as #32, hardcoded UI string on a no-op dispatch.

Closing this issue rather than fixing it directly because:

  • The actual API bugs are the canonical root causes — fixing them is a separate workstream owned by Mark/org_mode's issue-fixer pipeline.
  • The UI bugs require rebuild work on ThreadCraft's combobox + state-machine, not a small patch.
  • Tracking these as separate issues dilutes the canonical bug list.

Re-open this if the canonical API bugs (#27-#31) are fixed and the UI symptoms persist independently.

Closed as duplicate of the original API-contract bugs filed earlier in this thread (#27, #28, #29, #30, #31 on Mark/easystitch-service). This issue describes a **UI symptom** of a deeper family of bugs. The UI cannot drive the digitize/export flow end-to-end because: 1. **#32 (silent no-op)** — root cause is `useWorkspace.ts:414-432` bailing silently when `state.uploadedImage` is null, plus `RightPanel.tsx:217` showing a hardcoded "complete!" message without ever firing the API call. The actual API contract bugs are in the service layer (#27, #28, #30, #31) — fix the server contract first, then the UI flow becomes verifiable. 2. **#33 (combobox click swallowed)** — root cause is a custom Radix-like dropdown wrapper in `RightPanel.tsx` that doesn't fire React `onChange` on synthetic events. The settings panel exists but is functionally inert; the only working path is the API directly. The user-facing impact is #31 (DigitizeSettings rejects fabric/stabilizer) — the user CAN'T set fabric/stabilizer through the UI at all, so the API's `extra_forbidden` rejection is moot until the UI is fixed separately. 3. **#34 (false-complete message)** — same root cause as #32, hardcoded UI string on a no-op dispatch. Closing this issue rather than fixing it directly because: - The actual API bugs are the canonical root causes — fixing them is a separate workstream owned by Mark/org_mode's issue-fixer pipeline. - The UI bugs require rebuild work on ThreadCraft's combobox + state-machine, not a small patch. - Tracking these as separate issues dilutes the canonical bug list. Re-open this if the canonical API bugs (#27-#31) are fixed and the UI symptoms persist independently.
Mark closed this issue 2026-09-10 02:53:59 +00:00
Mark commented 2026-09-10 02:54:56 +00:00
Author
Owner
Copy link

Reopening this issue. I previously closed it as "duplicate of #27-#31" — that was wrong.

The 3 issues in this thread (#32, #33, #34) describe client-side UI bugs in the ThreadCraft frontend that are NOT duplicates of the API-contract bugs (#27-#31) on Mark/easystitch-service. They live on different repos and represent a separate class of failure:

  • #32 (silent no-op) — Auto-Digitize button bails silently when state.uploadedImage is null. UI flow broken; user sees no error.
  • #33 (combobox swallowed) — FABRIC TYPE / STABILIZER / HOOP SIZE options render but clicking them does not update React state. Settings panel is functionally inert.
  • #34 (false-complete) — Confirm & Edit dispatches a hardcoded "Auto-digitize complete!" message without ever firing runAutoDigitize().

These bugs BLOCK the user from ever reaching the API surface that #27-#31 describe. They're prerequisite to fixing #27-#31, not duplicates of them. Closing them hides real UI bugs that need separate fixes on the ThreadCraft frontend repo (Mark/Kimi_Agent_Brother_10_Digitizing_App, not Mark/easystitch-service).

The 5 API bugs (#27-#31) remain open with the UI evidence I appended earlier. The 3 UI bugs (#32-#34) are now reopened and will be tracked independently.

The proper relationship is "blocks" (UI fixes unblock API verification), not "duplicate."

Reopening this issue. I previously closed it as "duplicate of #27-#31" — that was wrong. The 3 issues in this thread (#32, #33, #34) describe **client-side UI bugs in the ThreadCraft frontend** that are NOT duplicates of the API-contract bugs (#27-#31) on Mark/easystitch-service. They live on different repos and represent a separate class of failure: - **#32 (silent no-op)** — Auto-Digitize button bails silently when `state.uploadedImage` is null. UI flow broken; user sees no error. - **#33 (combobox swallowed)** — FABRIC TYPE / STABILIZER / HOOP SIZE options render but clicking them does not update React state. Settings panel is functionally inert. - **#34 (false-complete)** — Confirm & Edit dispatches a hardcoded "Auto-digitize complete!" message without ever firing `runAutoDigitize()`. These bugs BLOCK the user from ever reaching the API surface that #27-#31 describe. They're **prerequisite** to fixing #27-#31, not duplicates of them. Closing them hides real UI bugs that need separate fixes on the ThreadCraft frontend repo (Mark/Kimi_Agent_Brother_10_Digitizing_App, not Mark/easystitch-service). The 5 API bugs (#27-#31) remain open with the UI evidence I appended earlier. The 3 UI bugs (#32-#34) are now reopened and will be tracked independently. The proper relationship is "blocks" (UI fixes unblock API verification), not "duplicate."
Mark reopened this issue 2026-09-10 02:54:56 +00:00
Mark commented 2026-09-10 02:55:19 +00:00
Author
Owner
Copy link

Final disposition: this issue has been moved to the ThreadCraft frontend repo where the bug actually lives.

  • Original location: forgejo.tail018ac4.ts.net/Mark/easystitch-service/issues/34
  • New location: forgejo.tail018ac4.ts.net/Mark/Kimi_Agent_Brother_10_Digitizing_App/issues/62

Closing this issue on easystitch-service — the fix belongs on the frontend repo. The new issue has the full body and code-path references.

Final disposition: this issue has been **moved** to the ThreadCraft frontend repo where the bug actually lives. - Original location: forgejo.tail018ac4.ts.net/Mark/easystitch-service/issues/34 - New location: forgejo.tail018ac4.ts.net/Mark/Kimi_Agent_Brother_10_Digitizing_App/issues/62 Closing this issue on easystitch-service — the fix belongs on the frontend repo. The new issue has the full body and code-path references.
Mark closed this issue 2026-09-10 02:55:19 +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#34
No description provided.