[BUG] [alpha] Prompt Editor: dismissing modal (backdrop / X) during Save does not cancel persistence — create/update can still complete after user leaves

[galuis4a]

Project

ide

Description

Plain language

The Prompt Editor modal lets the user close it via the backdrop click or the header X at any time. Those paths do not check whether a Save is in progress (saving is only used to disable the primary Save button). If the user dismisses the modal while updatePrompt / createPrompt is still awaiting storage, the in-flight operation continues and can still write the prompt to disk and update the list. The user reasonably expects “close = discard unsaved work” (or at least “stop what Save was doing”); instead they can get ghost saves or new prompts created after the UI is gone.

This is the same async cancellation / late completion theme as bounty #38008 (API Tokens Cancel vs in-flight Save) but on a different surface (Prompt Library editor), so it is not a duplicate of that ticket—it extends the pattern.

Technical detail

Save path — setSaving(true), then await promptStore.updatePrompt / createPrompt, then closeEditor() in try:

    setSaving(true);

    try {
      const promptData = {
        title: title().trim(),
        content: content().trim(),
        description: description().trim(),
        category: category(),
        tags: tags(),
        isFavorite: isFavorite(),
      };

      if (isEditing()) {
        await promptStore.updatePrompt(promptStore.state.editingPrompt!.id, promptData);
      } else {
        await promptStore.createPrompt(promptData);
      }

      promptStore.closeEditor();
    } catch (e) {
      setErrors([{ field: "general", message: String(e) }]);
    } finally {
      setSaving(false);
    }

Dismiss paths — no guard on saving(); always call closeEditor():

  const handleClose = () => {
    promptStore.closeEditor();
  };

  return (
    <Show when={isOpen()}>
      <div
        class="fixed inset-0 z-[60] flex items-center justify-center"
        style={{ background: "rgba(0,0,0,0.6)" }}
        onClick={(e) => {
          if (e.target === e.currentTarget) handleClose();
        }}

Header close uses the same handleClose (lines 214–219 in file). Save is the only control that respects disabled={saving()} (see footer ~510).

PromptStoreContext.updatePrompt / createPrompt both await saveToStorage() — there is no cooperative cancellation.

Error Message

Debug Logs

System Information

OS: Windows 11

Screenshots

Steps to Reproduce

1. Open Prompt Library and start Create (or Edit an existing prompt).
2. Change fields, click Save Changes / Create Prompt (or equivalent).
3. Immediately click the backdrop (outside the card) or the X before the save finishes (slow disk or throttle helps).

Expected Behavior

• Dismissing the modal while save is in-flight either aborts the operation, or ignores completion so no partial/undesired persistence occurs; or dismiss is blocked until save completes (with clear UX).

Actual Behavior

Actual

• Modal closes (closeEditor()), but updatePrompt / createPrompt can still complete and persist data the user thought they cancelled. For create, a new prompt may appear after dismiss.

Suggested direction (implementation notes)

• While saving() is true: ignore backdrop/X or show confirm; or use a save generation id / let cancelled = false on open and check after await before applying side effects / second closeEditor().
• Align behavior with product decision: “Save is atomic and cannot be cancelled” → disable all dismiss affordances until finally runs.

Relation to existing issues

• [bug][alpha] CortexAccountPanel API Tokens: Cancel does not abort in-flight Save #38008 — API Tokens: same class of bug (cancel/dismiss vs in-flight async save). This report is Prompt Editor only; fixing one may inform the other but they are separate UI flows.

Additional Context

No response

[echobt]

❌ Invalid

The screenshot does not demonstrate the reported bug. The issue describes a race condition where dismissing the Prompt Editor modal (via backdrop click or X button) during an in-flight save operation allows the save to complete after the UI closes. However, the provided screenshot only shows the Prompt Store list view - it does NOT show the Prompt Editor modal, nor does it show any save operation in progress.

Per validation rules: "SCREENSHOT MUST BE RELEVANT. Even if the code has a real bug, the screenshot/video MUST actually show or relate to the reported issue. If the screenshot is unrelated, generic, recycled, or does not match the bug description = INVALID."

While code analysis of src/components/ai/PromptEditor.tsx confirms the reported bug pattern exists (handleClose() at line 166 doesn't check saving() state, allowing modal close during async save), the screenshot is completely unrelated to the described issue and shows only the Prompt Store list view instead of the Prompt Editor modal during a save operation.

[hinzwilliam52-ship-it]

This looks straightforward. I'm opening a PR with a solution in just a moment.

[hinzwilliam52-ship-it]

I have opened a Pull Request with the fix here: #38156

Thanks!