Announcements not quite working

[einari]

It looks like we have some sort of caching for announcements.
I made a change to an announcement and logged out a user and back in, and still the old banner was there.

This might be related, but I also tried adding an announcement in Admin and it didn't show up.

Multiple banner announcements should vertically stack them.

For multiple dialog announcements, the user should have to click through a "Next" button till all has been gone through and then be able to click Ok for closing.

[einari]

The stale banner is an ordering bug, and the events show it plainly. For announcement 46f81105 the Cratis tenant log reads:

OrganizationAnnouncementWithdrawn   46f81105   2026-08-14T01:08
OrganizationAnnouncementAmended     46f81105   2026-08-14T01:08
OrganizationAnnouncementPublished   46f81105   2026-08-14T01:08

In Admin the real order was authored 2026-08-13T17:26, withdrawn 17:27. The tenant received them reversed: [RemovedWith<OrganizationAnnouncementWithdrawn>] removed the read model, and the Published that arrived afterwards re-created it. Admin holds one announcement; every Core tenant holds two.

Cause

Receiving.cs bridges Admin's announcements into each tenant with three separate reactors - AnnouncementPublicationInbox, AnnouncementAmendmentInbox, AnnouncementWithdrawalInbox. Three reactors are three independent observers, each with its own position in the Admin inbox, so nothing orders a publication against the withdrawal that supersedes it. They only have to interleave once - a restart replaying a backlog is enough, which is what 01:08 was.

The tension

The file already explains why they are separate:

They are separate reactors so each keeps its own OnceOnly bookkeeping for that event source.

So the obvious fix - one reactor with three handlers, giving one observer and one order - runs into [OnceOnly], whose bookkeeping is per event source. If it is also per reactor rather than per handler, merging them would let the publication mark the event source done and the withdrawal be skipped, which is worse than the bug.

That is the question to settle before writing the fix, and it is a Chronicle semantics question rather than something to infer: is [OnceOnly] bookkeeping keyed per handler method, or per reactor per event source? If per handler, merging is a small and safe change. If per reactor, the bridge needs a different shape - a single handler over a common base event, or dropping [OnceOnly] and making the tenant-side append idempotent some other way.

Worth noting the amendment inbox already runs without [OnceOnly] deliberately, since an announcement can be amended repeatedly - so the three are not symmetric to begin with.

Still to do on this issue

• Banner stacking for multiple persistent announcements.
• Dialog announcements: step through with Next and close with Ok, instead of selectAnnouncements returning a single dialog via active.find(...).

Both are frontend-only and independent of the ordering fix.