-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC3269: An error code for busy servers #3269
base: old_master
Are you sure you want to change the base?
Conversation
Signed-off-by: David Teller <davidt@element.io>
## Alternatives | ||
|
||
We could rather decide that `M_RESOURCE_LIMIT_EXCEEDED` can also be used to mean that the user should wait before | ||
retrying, even if they're not the ones using too many resources. I suspect that this would be confusing, though. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is important to differentiate between retryable an non-retryable errors, so we should keep these separate.
|
||
This proposal introduces `M_SERVER_BUSY`, to be used when the server is too busy to respond right now, typically | ||
because a large number of pending requests, and the client should retry later. It is typically designed to be returned | ||
with a `retry_after_ms`, which hints how long the client should wait before retrying. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should they wait before trying this request? Or wait before retrying "similar" requests? Or should the pause all requests until the specified duration?
It seems like this is too little information to go on, especially on batch and expensive operations such as an initial sync.
|
||
## Security considerations | ||
|
||
I can't think of any security issues that this could cause. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Potential attacker/spammer would programmatically know they've succeeded, although I can't say I know how this information would be useful.
No description provided.