@daniel Would you be willing to take a look? For now, I subscribed to PageDeletedEvent and PageRevisionUpdatedListener separately, but as far as the docs say, that shouldn't be necessary. We'll be going ahead with the separate events for now to fix T401322 (given there is no response/movement on this task), but I still think the behaviour should be corrected (or the docs, depending on which one is wrong).

The issue seems to be this bit of code:

                $pageBefore = $event->getPageRecordBefore();
		if ( $pageBefore === null ) {
			// Nothing to do here. The page did not exist before, so cache cannot be populated.
			return;
		}

The assumption that the cache doesn't need to be invalidated if the page didn't previously exist seems reasonable, but is apparently wrong. Maybe the cache gets populated with an empty value by a previous attempt to read the config? Or it's carried over from another test?

In any case, the final version of your patch has:

        public function handlePageRevisionUpdatedEvent( PageRevisionUpdatedEvent $event ): void {
		$this->invalidateForPage( $event->getPage() );
	}

This unconditionally invalidates the cache when a revision is created, including the case when the page didn't previously exists. That works.

The implementation of PageRevisionUpdatedEvent::getPage() is return $this->getPageRecordAfter(). if we change our original code accordingly, it works:

                $pageBefore = $event->getPageRecordBefore();
		if ( $pageBefore === null ) {
			$page = $event->getPageRecordAfter();
		}

In summary, you hit the fact that the behavior of PageRecordChangedEvent::getPageBefore() is not the same as PageRevisionUpdatedEvent::getPage().

Note btw that getPageRecordBefore() is still needed to handle the deletion case. When using PageRecordChangedEvent, you need to check both, getPageBefore() and getPageRecordAfter(). Or you can use getPageId(), if all you needd is the ID. It's tempting to create a getPage() method that will never return null, we used to have that. But it's unclear what it should return in the case of page moves, so we removed it.

That reminds me - how should page moves be handled in your case? Should the cache be invalidated for the old title, or the new? Or both?

PS: NewcomerMilestoneIngressTest always failes for me in the way aou descfribe above, even on latest master. That issue seems unrelated.

PPS: If you use PageRecordChangedEvent, you may get multiple events for the same user action - creating a page causes a PageLatestRevisionChangedEvent (aka PageRevisionUpdatedEvent) and also a PageCreatedEvent (in that order, because page creation is not complete until after the first revision has been created). Similarly, moving a page will trigger a PageMoved event and as well as a PageLatestRevisionChangedEvent for the dummy revision.