Hi, probably a really niche question and one for @Ronald Barendse - but I've noticed when you suppress notifications in v12 (within a core scope), and then fire them later on with a

ScopedNotificationPublisher

then I've noticed that the notifications still go through one at a time, rather than say their being one

ContentSavedNotification

with all the

savedEntites

, I get an individual notification for each entity. each containing just a single item. Is this by design ? or have I missed a thingy somewhere on the whole suppress / publish workflow where it will combine them ? not a biggie but if there is a flag/method or something - it would be nice to give it a go.

Hi Kevin! To be honest, we still need to update the documentation on https://docs.umbraco.com/umbraco-cms/reference/notifications on how multiple notifications can be handled, when that's the case and what the new

IDistributedCacheNotificationHandler

marker interface should be used for 😉 There's a couple of things that need to happen/align before you can handle multiple notifications: 1. Notifications need to be published within an Umbraco scope (as

ScopedNotificationPublisher

will publish them when the scope is completed/disposed) 2. They are chunked/only grouped when multiple consecutive notifications of the same type are published, see https://github.com/umbraco/Umbraco-CMS/pull/14332#discussion_r1219303413 3. The `INotificationHandler`/`INotificationAsyncHandler` interfaces have a default implementation that iterates over the notifications for backwards compatibility, so you need to manually override this

yeah, i thought so, I am a little reluctant, not to fire all notifications to be honest, while just firing cache refreshers will get the core stuff all working as expected ? - people with custom code listening for save events etc, might be a little grumpy if they don't get the event when an item is synced for example (although to be honest these events are a pain and often the answer to "why is my site syncing slowly?" is because you have slow custom events) I was thinking that, the events are raised individually so you would have to do something special to merge them into a "single multiple item event" and even then i am not sure (because i don't know all the bits that hang off a notification) if that doesn't risk losing something 🤷‍♂️

Note that

ScopedNotificationPublisher

(by default) won't publish cancellable notifications on scope exit, as that would prevent you from actually cancelling the notification. However, in Deploy we do suppress all events in a subclassed publisher that sets

publishCancelableNotificationOnScopeExit: true

and overriding

PublishScopedNotifications(...)

to group all notifications by type (to ensure they are all chunked/grouped together) and only publish them to handlers that implement `IDistributedCacheNotificationHandler`:

csharp
// Group notifications by type, since we don't care about the original order they were published in
var groupedNotifications = notifications.GroupBy(x => x.GetType()).SelectMany(x => x);

// Handle all distributed cache refreshers (including Deploy refreshers)
_eventAggregator.Publish<INotification, IDistributedCacheNotificationHandler>(groupedNotifications);

This is all fine, because we don't care about the order of notifications when updating the distributed caches (cache refreshers, which are used for updating NuCache, IAppCaches and Examine indexes) or the notification state... The base class for these handlers therefore only return the entities of all notifications: https://github.com/umbraco/Umbraco-CMS/blob/contrib/src/Umbraco.Core/Cache/NotificationHandlers/DistributedCacheNotificationHandlerBase.cs You could achieve something similar by suppressing all notifications and manually rebuilding all caches, which is still how it's done within migrations: - https://github.com/umbraco/Umbraco-CMS/blob/contrib/src/Umbraco.Infrastructure/Migrations/MigrationPlanExecutor.cs#L252 - https://github.com/umbraco/Umbraco-CMS/blob/contrib/src/Umbraco.Infrastructure/Migrations/MigrationPlanExecutor.cs#L107

Yeah the uSync one is very similar. we've grouped them (it shouldn't actually matter with the way uSync already chunks up its processing by type) mainly for the UI so we can tell people that we've fired off all the 'content' notifications for example. and we're not suppressing cancels - because well people might want to cancel 🙂 it all works ok, just notifications are then singular, which again isn't a massive issue, but performance wise might be something that could be quicker if we grouped them.

Because suppressing all events isn't extensible, as you'd need to know implementation details of what caches need to get updated and it could actually rebuild things that haven't changed, this seemed like the best approach...

yeah - its more deferring to the end than suppressing really 🙂

Indeed and if you already group all notifications by type, the CMS will ensure things like the NuCache is rebuilt a single time, which was the biggest performance improvement we noticed