/createRoom has a very confusing failure mode when the invite option is used on a Synapse that has third party synapse modules, bridges or bots that are appending events unrelated to the client making the request

[Gnuxie]

Description

We were offering support to a system admin setup up a Draupnir instance, and when they tried to use Draupnir's list create command (which in turn calls /createRoom), their Synapse tripped up on this event authorization code and returned the following response to Draupnir.

POST /_matrix/client/v3/createRoom: 403 Forbidden -- {"errcode":"M_FORBIDDEN","error":"@invited_moderator:example.com is already in the room."}

This is because Draupnir sets the invite option for /createRoom to ["@invited_moderator:example.com"], however for some reason that we have not been able to work out (because /createRoom failing during event authorization is particularly unhelpful) Synapse believed @invited_moderator:example.com to already be present within the room. While the system admin believes there are no bots, synapse modules, or appservices which would inject their membership into the newly created room, we cannot provide that guarantee. You should ask yourself whether it would be possible for a Synapse module, bridge or bot to inject membership events into a room before Synapse has even responded to the /createRoom request that is supposed to create the room. And you should then ask yourself whether it is safe or sound for a synapse module to inject events into a room before Synapse has finished processing the /createRoom request. Specifically because this causes the request to fail for the innocent client, rather than the clobbering performed by the synapse module or appservice to fail -- the wrong party is getting hit for playing around unsafely.

I maintain that the system admin was oblivious to any synapse modules, bots, or appservices that could be causing this issue.

Steps to reproduce

These steps that could reproduce the failure mode, this is not how the failure mode was experienced, and I have not tested them and am not going to do without some persuasion.

• have a user called @bob:example.com
• have a Synapse module that injects @bob:example.com into the membership of each newly created room upon m.room.create
• with another user @alice:example.com, call /createRoom with @bob:example.com in the invite option.

Homeserver

unknown

Synapse Version

v1.98.0

Installation Method

I don't know

Database

unknown

Workers

Single process

Platform

unknown - the version provided is accurate though.

Configuration

No response

Relevant log output

I don't have access to the log, if you're unhappy with that just close the issue.
I might be able to obtain it from the admin at a later date if necessary.

Anything else that would be useful to know?

No response

[reivilibre]

Seems like another problem that essentially boils down to /createRoom not being atomic, e.g. matrix-org/synapse#8895

I maintain that the system admin was oblivious to any synapse modules, bots, or appservices that could be causing this issue.

This is peculiar; if you could convince them to provide logs that would be interesting indeed.

Wild speculation: Don't suppose it might be a case where @invited_moderator:example.com is creating a room and inviting itself?

Aside from that, the problem with modules is itself unfortunate.