Skip to content

fix(use-toast-mutation): show error toast when successMsg is null#2294

Merged
peppescg merged 1 commit into
mainfrom
fix/toast-mutation-error-when-success-null
May 28, 2026
Merged

fix(use-toast-mutation): show error toast when successMsg is null#2294
peppescg merged 1 commit into
mainfrom
fix/toast-mutation-error-when-success-null

Conversation

@peppescg

Copy link
Copy Markdown
Collaborator

Summary

Fixes #2293.

useToastMutation was silently swallowing mutation errors when callers passed successMsg: null. The entire toast.promise(...) call — including the error: branch — was gated on a non-null success message, so any configured errorMsg became dead code.

This PR registers toast.promise whenever a success message or an error message is configured, and only emits the success: key when applicable. The silent-mode escape hatch (successMsg: null with no errorMsg) is preserved.

Behavior matrix

successMsg errorMsg Before After
set any toast on success + error toast on success + error (unchanged)
null set silently swallowed toast on error
null unset silent silent (unchanged — explicit opt-out)

First observed in ToolHive Studio Enterprise's signin page, where a backend-unreachable scenario produced zero UI feedback (related downstream: stacklok/stacklok-enterprise-platform#1300).

Test plan

  • New regression test in renderer/src/common/hooks/__tests__/use-toast-mutation.test.tsx covers:
    • Success path with successMsg set
    • Failure with successMsg: null + errorMsg (the bug scenario)
    • errorMsg as a function receiving the error
    • Silent mode (successMsg: null, no errorMsg)
    • Fallback to error.detail when no errorMsg
    • toastId pass-through
  • pnpm run lint
  • pnpm run type-check
  • All hook tests pass

🤖 Generated with Claude Code

The entire `toast.promise(...)` call — including the `error:` branch —
was gated on `resolvedSuccessMsg !== null`, so any configured `errorMsg`
became dead code when callers passed `successMsg: null`. This silently
swallowed mutation errors in flows that legitimately suppress the
success toast (e.g. routes that navigate away on success) but still
want user-visible error feedback.

Register `toast.promise` whenever a success message or an error message
is configured, and only emit the `success:` key when applicable. The
silent-mode escape hatch (`successMsg: null` with no `errorMsg`) is
preserved.

Fixes #2293

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings May 28, 2026 11:46

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes useToastMutation so callers can suppress success toasts while still showing configured error toasts, addressing the silent failure scenario from issue #2293.

Changes:

  • Registers toast.promise when either a success message or an error message is configured.
  • Omits the success toast config when successMsg resolves to null.
  • Adds regression tests covering error-only, silent, fallback, function-based error message, and toastId behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
renderer/src/common/hooks/use-toast-mutation.ts Updates toast registration logic to support error-only toast handling.
renderer/src/common/hooks/__tests__/use-toast-mutation.test.tsx Adds tests for the hook’s success, error, silent-mode, fallback, and toastId behavior.

@peppescg peppescg self-assigned this May 28, 2026
@peppescg peppescg merged commit ad184c4 into main May 28, 2026
18 checks passed
@peppescg peppescg deleted the fix/toast-mutation-error-when-success-null branch May 28, 2026 12:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: useToastMutation silently swallows errors when successMsg is null

3 participants