This behavior was initially introduced in D590. At the time, we were shimming SIDEBAR_SOURCE on codeVersions older than 75. We eventually stopped supporting versions that old, and now UNSUPPORTED is only sent for a SIDEBAR_SOURCE if the sourceMessage is missing.

Since we include SIDEBAR_SOURCE in localUnshimTypes, the UNSUPPORTED message actually gets unshimmed immediately upon being received on the client, which negates the purpose of shimming it in the first place. So it makes no sense to both have the unshimming logic, and to include SIDEBAR_SOURCE in localUnshimTypes.

I initially considered removing SIDEBAR_SOURCE from localUnshimTypes, which would mean that the message would just appear as the robotext "first message in thread". This seemed like @tomek's initial intention when making the change in D590.

But it looks like following this discussion in D632, @tomek added an if (!sourceMessage) return null condition to what is now createMessageInfo, which means that without the unshimming logic, the SIDEBAR_SOURCE simply would not be rendered on the client.

I tested both solutions and found that if the client couldn't find the SIDEBAR_SOURCE in the MessageStore for the child thread, it would just pull it from the parent thread in the MessageStore. (I'm guessing this exists to make the pending thread work.) Comparing the two visual results below, it seemed like simply not shimming (and letting the client ignore the SIDEBAR_SOURCE) was a better option than shimming it as "first message in thread".

Here's what it looks like if we remove SIDEBAR_SOURCE from localUnshimTypes and shim the SIDEBAR_SOURCE message on the keyserver side:

Here's what this solution looks like, where we remove the shimming logic and send a SIDEBAR_SOURCE without a sourceMessage to the client:

Note that I checked it as a sender and recipient, and it looked the same on both. Also tried logging out and then back in as the sender, and still saw the same thing.