Notes Notifications queue excessively and continue appearing long after actions complete

[karthick-murugan]

Description

While testing a scenario involving a high number of note state changes (e.g., repeatedly resolving and reopening the same note to generate 100+ replies), the notification system becomes extremely slow and unresponsive.

Each “Resolve” and “Reopen” action triggers a notification such as:

• Note marked as resolved
• Note reopened

However, instead of appearing immediately and clearing normally, these notifications get queued and continue displaying one after another for 5–10 minutes after the actions have already finished.

This results in a prolonged stream of notifications even though no further user actions are occurring.

Step-by-step reproduction instructions

1. Add a note to a block.
2. Repeatedly toggle its state (Resolve → Reopen → Resolve → Reopen) approximately 20 or 30 times or more.
3. Observe the notification behavior during and after the test sequence.
4. The notifications continue appearing for several minutes after the last toggle action.

Expected Behavior

• Notifications should appear and clear promptly.
• Notification queue should be processed in real time, without excessive backlog.
• UI should not continue displaying notifications long after all actions are completed.

Screenshots, screen recording, code snippet

REC-20251125164430.mp4

Environment info

WordPress version (6.9-RC2)
Gutenberg Version 22.1.2
MacBook Pro
Chrome Version 142.0.7444.176

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[Mamaduka]

@karthick-murugan, can you include the network tab in this screencast? I think the REST API calls are queued; the snackbars are displayed after a successful request.

Repeatedly toggle its state (Resolve → Reopen → Resolve → Reopen) approximately 20 or 30 times or more.

While I appreciate stress testing, this behavior seems highly unlikely in real-world scenarios.

[karthick-murugan]

@Mamaduka I’ve uploaded a new screencast with the Network tab included. As you can see, the REST API calls are not getting queued — they return immediately — but the UI still ends up in an incorrect state after several Resolve ↔ Reopen toggles.

I agree that doing this 20–30 times is not a usual real-world action, but the test helps expose an underlying UI state issue. Even with fewer toggles (or fast clicks), users can still hit this inconsistent state.

So I think it’s worth considering a fix, since it affects how reliably the Notes status updates in the sidebar.

REC-20251202114851.mp4

[Mamaduka]

Thanks for the new screencast.

The editor only displays the last three notices when many are dispatched. This is to avoid flooding the screen with notices - #58598.

Based on this, I don't think this problem (if we call it that) is unique to the Notes feature, which makes me wonder whether we really need notices for these actions; maybe we can communicate status changes better in the UI. cc @jasmussen

Somewhat related conversation regarding the Toasts pattern and its usefulness - https://wordpress.slack.com/archives/C02QB2JS7/p1763280882488139 (requires Slack login).

[jasmussen]

Good issue, good instincts. I would agree personally that I don't think resolve, reopen, need snackbars. They seem clear enough in their respective contexts: you click an action and you immediately experience the result. There's no need to "Undo" the action, which is usually a motivation to show a snackbar. Or to get additional information when the result is ambigious, such as "copied blocks". I also still think we need to drastically reduce the 10s time those snackbars sit on screen.

I'd like to also extract the question posed at the end: what really is the best use case for snackbars? As I mentioned, "Copied all blocks" or "Copied color" feels useful as a snackbar, since those actions can otherwise lack meaningful visual differentiation. But many other actions arguably don't need them, and benefit from closer-to-the-context changes. I share that mostly as high level thinking for future feature work: what are ways we can convey a change that doesn't requite a snackbar?

[Mamaduka]

what are ways we can convey a change that doesn't requite a snackbar?

One UI that comes to mind is the URL in the post publish panel, which toggles the "Copy/Copied!" labels on the action. We should also keep A11Y in mind so that the status change is communicated correctly to users in every scenario.

cc @joedolson

Screencast

CleanShot.2025-12-02.at.14.35.29.mp4

[jasmussen]

It's not clear to me that changing the label of the button is actually good, as you allude to yourself, and I happen to think that particular UI is one of the few good use cases for a snackbar. Though it could also be argued that the button click would cause a tooltip to appear in context of the button and the click. If this were a video game, a number would arguably animate upwards from the button 😅

[joedolson]

Changing the label of an active button is generally not great, as it can be confusing for screen readers - whether or not the change of accessible name will be announced is highly variable. And when I say that, I mean that not only is it possible the user won't be notified of the change, they may even still get the previous name when they focus the control a second time. Better not to change the button label and have a visible/aural notice of some other type.

I do agree that resolve and reopen don't need snackbars; the result of those actions is already visible, and the extra visible notification is just making things busy.