feat(ui): expose cancel_synthesis in the queue entry menu - #174
Merged
Conversation
Expose the existing cancel_synthesis command in the per-entry menu, enabled only while the entry is processing; failures surface as an error notification. Resolve the menu entry from live state instead of the right-click snapshot so actions always see the current status.
This was referenced Aug 1, 2026
xilec
added a commit
that referenced
this pull request
Aug 1, 2026
## Summary - `cancel_entry` previously flipped **any** entry to `pending` unconditionally. A cancel arriving after the entry left `processing` (the race fixed frontend-side in #174: synthesis finishes while the context menu is open) silently regressed a `ready`/`error` entry and orphaned its audio from the state machine (playback requires `ready`; the entry would be re-synthesized on the next trigger). - Now `ready`/`playing`/`error` are rejected with `synthesis_error` before touching the registries or storage — same error style as `play_entry`'s "entry is not ready". - `pending` stays allowed **deliberately**: cancel is idempotent for idle entries (existing #129 orchestration test pins this), and a just-added entry briefly sits in `pending` with its synthesis task already registered — rejecting it would break that window. - OpenSpec change `harden-cancel-entry-status-guard` archived; `ipc-commands` spec updated (idle-cancel allowed, terminal-entry rejection, new scenarios). ## Test plan - [x] `cargo test` — 974 passed (new: reject `ready`/`error` with registries untouched; `pending` with a registered task still aborts it) - [x] `just lint` green - [x] `openspec validate --specs --strict` green ## Follow-up (not in this PR) A µs-scale read-decide-write race remains between `require_entry` and `update_entry` (guard reads a clone, synthesis can complete before the write). Closing it needs a storage-level compare-and-set, which would also harden `apply_ready_if_current`/`apply_error_if_current` — will be filed as a separate tech-debt issue. Closes #176
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
QueueList, enabled only forprocessingentries, calling the existingcancel_synthesisTauri command (backend landed in pipeline: leading-dot decimals like ".5" are never read #147).entriesstate instead of the right-click snapshot, so the item can't be triggered against an entry whose status changed while the menu was open (found in review: cancel on a just-finished entry would have silently flipped it back topending).expose-cancel-synthesis-menuarchived;queue-lifecyclespec updated ("Per-entry actions").Test plan
pnpm test:unit— 129 passed (newQueueListcomponent suite: cancel click dispatches the command, item disabled for ready/playing/pending/error, rejection shows the error notification)just lintgreencargo testgreenFollow-up (not in this PR)
Backend
cancel_entryflips status topendingunconditionally — worth hardening to a no-op/error unlessprocessing(separate issue).Closes #161