Skip to content
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

Draft
wants to merge 3 commits into
base: old_master
Choose a base branch
from

Conversation

Yoric
Copy link

@Yoric Yoric commented Jul 6, 2021

No description provided.

@Yoric Yoric marked this pull request as draft July 6, 2021 12:43
Signed-off-by: David Teller <davidt@element.io>
@uhoreg uhoreg changed the title MSCXXXX: An error code for busy servers MSC3269: An error code for busy servers Jul 6, 2021
@uhoreg uhoreg added kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal labels Jul 6, 2021
proposals/3269-server-busy.md Outdated Show resolved Hide resolved
## 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.
Copy link

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.
Copy link

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.
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants