How does umbraco handle pushing when done from a list view collection or a parent along with it's children?

I am writting a package that hooks into the ContentSavingNotificationhandler and loops though all SavedEntities in the notification. And I am getting in to a fight with Claud. It says that When a parent that has children or list view collection is published and there are mutiple nodes selected that the notification is fired one at a time for each content node but I thought Umbraco bunlded all the nodes into a collection and passed the entire collection to the notification handler.

The code I have is (this is sudo code)



public class Handler :  INotificaitonHandler<ContentSavingNotification>
foreach (var node in ContentSavingNotification.SavedEntities)
{
  check for error
    {
       ContentSavingNotification.CancelOperation; return;
    }
}

Now I thought that would just cancel the publish on the single node and then move on to the next in line, but Claud says it will cancel the whole batch and there is no way to just cancel the save of that one node and move on.

Am I right, is Claud right, are we both wrong?

I think in this instance Claude is sort of right, but it doesn’t matter.

if you cancel the notification it will indeed cancel the whole lot.

but at this time (v17/18) i don’t *think* there is actually a case inside umbraco where it will send bulk ContentSavingNotifications

from what i understand of the current layout the ContentSave Notification is sent individual for each save, even when something asks for a bulk save.

there are other notifications that might be batched up, but based on the flow (and i might be wrong, but i am fairly certain). the Saving ones are always individual,

but: they are coded to take multiple entries, so you can’t guarantee they always will, but if that changes i would expect it to be a breaking change, so not likely in v17/18 would be my guess.

Thanks for this information. I will take Claude being sort of right as me being sort of right and a win for me over AI :stuck_out_tongue:

Good to know that I don’t have to rewrite my handler at this point.