I'm not sure if this is the right constant to use here / what to do prior to landing.

Before landing, should I replace it like usual with current code version + 2 to include public and staff releases Or is that part of the release process now and I should leave it as is?

What's the || null for? Typically ?? null is preferred is you really want to coerce to null, but I'm not clear on why you want to do that

?? instead of ||

Or is that part of the release process now and I should leave it as is?

That's the idea, but it helps to ping @atul to give him a heads-up

Should we make this look more like the result of the robotext function? Is it possible to factor out the assigned ${affectedUsers} the \"${roleName}\" role part of the robotext method and call it here?

Worth noting that there are some nuances here for converting from`EntityText` to a string since it requires ENS resolution. Some ideas:

1. Call entityTextToRawString and accept that ENS resolution would not occur
2. Use "some members" or "a member" instead of affectedUsers for this case, so that ENS resolution doesn't matter. Then you can call entityTextToRawString without worrying
3. (Best but hardest) call getEntityTextAsString and do ENS resolution, but first you'll need to convert shimUnsupportedMessageInfo and shimUnsupportedRawMessageInfos into async functions

I thought the idea was that older clients won't have access to the new roleName field in the first place, so we'd have to shim the message. The original way we're getting the roleName is by accessing threadInfo.roles[messageInfo.newRole].name, but I took a look at the message-spec and it doesn't look like there's a way we can access params to get the threadInfo.

TLDR of that is I don't think we can access the role name for older clients with just the messageInfo.

Unless maybe I'm misundestanding the problem with 'older clients', and accessing messageInfo.roleName here won't actually be an issue

I think shimUnsupportedMessageInfo gets called on the keyserver, not on clients

Ah yeah good point

Yeah the backslash is needed to escape the " character, since we want to display something like you assigned jake the "Moderators" role (change was made last month in D8142).

They won't get rendered to the screen since they're escaped, this is what it looks like

Yeah we should be able to assert this with no problem, since we considered two cases:

1. Currently, the only roles are Members and Admins (neither can be deleted, so we can ensure that for all old role change messages, the role name will be in threadInfo.
2. For newer roles created (after this stack lands), they will also be available in the threadInfo. Once deleted, the newly introduced roleName field in the change role message info will be the 'fallback' option.

Just to be safe though, since constructChangeRoleEntityText already allows roleName to be optional for the case where we're shimming it, I can remove the invariant and pass in the roleName as-is. I expect it will always exist, but it'd be good to avoid an unnecessary crash