Finer granularity error codes in order to support i18nized errors from the server

[ara4n]

Right now there are many APIs where we return a generic 400,403,404 etc with a human readable error in English but no finer-granularity error code which a client could pick up and present a proper i18nized error message. Surely we need some kind of solution for this - whether it's either mandating servers do the i18n for errors themselves based on Accept language headers, or having much more sophisticated and finer granularity errors.

A good example is the groups API:

Matthews-MacBook-Pro:synapse matthew$ grep -ri 'group' . | fgrep \" | grep -i error | fgrep .py:
./groups/groups_server.py:            raise SynapseError(400, "Group not on this server")
./groups/groups_server.py:            raise SynapseError(404, "Unknown group")
./groups/groups_server.py:            raise SynapseError(404, "Unknown group")
./groups/groups_server.py:                raise SynapseError(403, "User is not admin in group")
./groups/groups_server.py:            raise SynapseError(404, "Unknown group")
./groups/groups_server.py:            raise SynapseError(403, "User not in group")
./groups/groups_server.py:            raise SynapseError(403, "User not invited to group")
./groups/groups_server.py:            raise SynapseError(403, "Group is not publicly joinable")
./groups/groups_server.py:                raise SynapseError(403, "User is not admin in group")
./groups/groups_server.py:            raise SynapseError(400, "Group already exists")
./groups/attestations.py:            raise SynapseError(400, "Attestation has incorrect group_id")
./groups/attestations.py:            raise SynapseError(400, "Neither user not group are on this server")
./storage/group_server.py:            raise SynapseError(400, "room not in group")
./storage/group_server.py:            raise SynapseError(400, "user not in group")
./federation/transport/server.py:            raise SynapseError(403, "group_id doesn't match origin")

Where clients will not only want to i18nize but also s/group/communities/ for presentation to the user (see element-hq/element-web#6003).

Related: https://github.com/matrix-org/matrix-doc/issues/1638 and https://github.com/matrix-org/matrix-doc/issues/603

[turt2live]

More granular error codes are spread out over quite a few issues in the repo ftr.

[KitsuneRal]

You already started doing it with M_ errors - please just do it across the board. Just adding l10n to the server is unlikely to be much beneficial as there's more than one homeserver implementation anyway; I'd say that it's a good work for client SDKs.

[turt2live]

Further, we should consider making it so clients can actually provide helpful strings. See also:

• "Failed to make_join via any server" is not useful feedback to the user element-hq/element-web#17740
• Specific ResourceLimitError messages are not displayed when trying to log in via SSO element-hq/element-web#17520
• Cannot join room from matrix.to link, "No known servers" element-hq/element-web#11756
• We mask the error when inviting users to a room which is blocked on a remote server element-hq/element-meta#1637
• Missing error message from nice error message box element-hq/element-web#10151
• 403 on removing an alias shows the wrong error dialog. element-hq/element-web#9308
• Consider ignoring the server's message when accepting an invite 401's element-hq/element-web#9247

All of these are cases where the server either provides a bad error message and the client tries to correct for it (badly), or the server provides a bad error message and the client trusts that message to be helpful (when it's not).