Open turt2live opened 6 years ago
Sounds sane to me, but are there other ways for joining of rooms to fail which we might also like to consider as error codes?
Oh probably. Those may be better to track separately, although they'll likely all end up in the same proposal.
If you don't get to it, I'll try to track them down tomorrow morning. I'm sure synapses issue list is ripe with them. Definitely would like to land several error codes into a single proposal than have them all appear as half page douments.
Sorry for interfering but should codes like that even be specced at all or left as a certain server's implementation detail? To be frank, I as a client author have no idea how to explain that kind of error to a user - at the same rate I'd show a generic "failed to join".
I'd also imagine most clients won't make use of them. If there's ever a client specifically geared at highly technical users, that would be the client that'd use them.
This would be more helpful for systems which use the API but not in a way that is exposed to humans. What prompted this particular issue was a project of mine where I needed to verify that a room was no longer joinable after making changes to the state and leaving. Currently that means relying on the implementation-specific error message, which is not safe if someone were to run this on another server implementation. Having a specific error code helps solve this issue.
Bots may be able to make use of this particular error code as well. They may want to retry a different room or communicate the error in more detail to the user.
There are a couple places where the action may not be able to be performed due to the lack of servers in the room. The easiest case is joining rooms. Currently synapse gives a 404 M_UNKNOWN error back to the client, which doesn't help for things like acceptance tests for things running against matrix or clients which want to be more proactive.
Adding and using a new error code (M_NO_SERVERS?) would be nice to have.