I think this is happening because CentralAuth sets the session source to local for anons? So you get a CA -> Local merge conflict if the session has expired, and maybe a Local -> CA one on login? (They seem to be happening with a comparable frequency.)

Maybe there could be a separate source for anons, which can be merged quietly with anything?

It looks like we have two cases here:

1. User is not logged in, but has a session with CentralAuthSource = Local. They log in on a different wiki. Then the next page load, CA sees the CA cookies and returns a SessionInfo with CentralAuthSource = CentralAuth. Merge fails with this exception.
2. User is logged in, and has a session with CentralAuthSource = CentralAuth. They somehow get logged out centrally. Then the next page load, CA sees no or invalid CA cookies and returns a SessionInfo with CentralAuthSource = Local. Merge fails with this exception.

I think in both cases I think it would be safe to implement CentralAuthSessionProvider::mergeMetadata() to always return the old CentralAuthSource value, and also adjust CentralAuthSessionProvider::refreshSessionInfo() to use 'Local' instead of skipping the check entirely when $info->getUserInfo()->getName() === null and reduce its own log message level. Or we could have it "merge" the new value to a different key and have CentralAuthSessionProvider::refreshSessionInfo() reject if that different key is set.

Or we could just reduce the log level of the exception in the first place. That'd certainly be safe.

In T158365#3036725, @Anomie wrote:

Or we could just reduce the log level of the exception in the first place. That'd certainly be safe.

Maybe add a severity parameter to ˙MetadataMergeException`? For CentralAuth it seems uninteresting, but maybe for some other provider it only happens when something is being tampered with?

A year later, this is still a fairly common warning in production (~17,000 hits in the past 7 days).

@AMooney: Assuming that "Set projects" was accidentally used instead of "Add projects", hence restoring some previous project tags.

Recent examples:
https://logstash.wikimedia.org/goto/e13abb4a6f31afe6b0671c1480bc6190

This is not necessarily an error, but really needs better documentation.

Untagging from production error, since this is a diagnostic warning in the session channel. It is not a runtime error or otherwise an uncaught exception in the error channel.