[Bug]: Queued toasts are not handled by dismissToast and dismissAllToasts #37123

Component

Toast

Package version

9.8.5

React version

19.3.1

Environment

System:
    OS: Windows 11 10.0.26200
    CPU: 11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHz
    Memory: 15.7 GB
  Binaries:
    Node: 26.13.0
    npm: 12.2.2
  npmPackages:
    @fluentui/react-components: 9.75.1 => 9.75.1
    @fluentui/react-toast: 9.8.5 => 9.8.5
    react: 19.3.1 => 19.3.1
    react-dom: 19.3.1 => 19.3.1

Current Behavior

Three cases where a toast that is queued behind the limit option is not handled by imperative dismissal. All three reproduce on master and none of them come from #36865.

1. dismissAllToasts gives queued toasts no status. queue.clear() drops them without calling onStatusChange, so a consumer tracking status never sees dismissed for a toast that was never shown. This is also mentioned by Victor Genaev (@mainframev) on [Bug]: Inconsistent toast status #36862.

2. A cleared queued toast id cannot be reused. The toast stays in the toasts map because remove() is only called from useToastContainer, which never runs for a toast that was never visible. A later dispatchToast with the same toastId returns early at if (toasts.has(toastId)) and nothing renders.

3. dismissToast on a queued toast does nothing. The toast still becomes visible once a slot frees up.

Verified against @fluentui/react-toast@9.8.5 with the script in the reproduction link. Observed output:

CASE 1 dismissAllToasts on a queued toast
  b queued (in map, not visible): true
  status callbacks: ["a:null","b:null"]
  b still in toasts map: true
  b reported dismissed: false

CASE 2 reuse a cleared queued id
  b in map before re-dispatch: true
  b visible after re-dispatch: false

CASE 3 dismissToast on a queued toast
  y visible before: false
  y still in map after: true
  y visible after: false

Expected Behavior

1. A queued toast removed by dismissAllToasts reports dismissed through onStatusChange.
2. A queued toast removed from the queue is removed from the toasts map, so its toastId can be dispatched again.
3. dismissToast removes a queued toast so it never becomes visible when a slot frees up.

On the duplicate warning above: this is distinct from #36862, which covers status for toasts that are visible and is addressed by #36865. Every case here involves a toast that was queued behind limit and never became visible, so #36865 does not change any of them. All three reproduce on master independently of that PR.

Reproduction

https://gist.github.com/jakesalvesen/fe3c8f26a9259942612262942bcf43f7

Steps to reproduce

1. In an empty directory run npm i @fluentui/react-toast@9.8.5 react@19 react-dom@19.
2. Save repro.cjs from the gist and run node repro.cjs.
3. App.jsx shows the same three cases through the public API, using useToaster({ limit: 1 }) and useToastController.

The script creates a toaster with limit: 1, dispatches two toasts so the second one is queued, then dismisses imperatively and reads toasts.has(...) and isToastVisible(...).

Are you reporting an Accessibility issue?

no

Suggested severity

Medium - Has workaround

Products/sites affected

No response

Are you willing to submit a PR to fix?

yes

Validations

• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.