Describe the bug
Sending a chat message is refused with rate-limited: quota exceeded; retry in Ns, even though the user has sent nothing else.
The WebSocket admission budget is one bucket per pubkey covering both subscription requests (REQ) and published events (EVENT). A client that opens many channel subscriptions — at app start, or when replaying live subscriptions after a reconnect — spends that budget on its own bookkeeping, and the next message the user types is rejected. The bucket is also shared across devices, so a desktop client signed in as the same user draws from it too.
This became visible rather than new: an over-quota EVENT is now rejected on the OK channel, so the send fails with a reason. Previously the same rejection arrived as a bare NOTICE with no event id, and the send just timed out.
Steps to reproduce
- Run a relay with the default rate limits.
- Sign in as a user who is a member of many channels, on mobile and desktop at the same time.
- Open the mobile app, or let it reconnect after a network change, so it resubscribes to every channel.
- Type and send a message within the next few seconds.
- The send fails with
rate-limited: quota exceeded; retry in Ns.
Expected behavior
A user's own message should not be refused because the client spent the shared budget on its own subscriptions. Either give sends their own budget, or do not charge client-initiated sends against the subscription burst budget.
Version and platform
Buzz mobile on iOS, against a self-hosted relay built from main.
Logs / screenshots
Relay side, buzz_admission_rejections_total{transport="websocket",reason="quota"} climbs while the user is only reading and occasionally sending.
Closest existing report is #7019 (closed as not planned), where the desktop composer hung for the same reason before the rejection was made correlatable.
Describe the bug
Sending a chat message is refused with
rate-limited: quota exceeded; retry in Ns, even though the user has sent nothing else.The WebSocket admission budget is one bucket per pubkey covering both subscription requests (
REQ) and published events (EVENT). A client that opens many channel subscriptions — at app start, or when replaying live subscriptions after a reconnect — spends that budget on its own bookkeeping, and the next message the user types is rejected. The bucket is also shared across devices, so a desktop client signed in as the same user draws from it too.This became visible rather than new: an over-quota
EVENTis now rejected on theOKchannel, so the send fails with a reason. Previously the same rejection arrived as a bareNOTICEwith no event id, and the send just timed out.Steps to reproduce
rate-limited: quota exceeded; retry in Ns.Expected behavior
A user's own message should not be refused because the client spent the shared budget on its own subscriptions. Either give sends their own budget, or do not charge client-initiated sends against the subscription burst budget.
Version and platform
Buzz mobile on iOS, against a self-hosted relay built from
main.Logs / screenshots
Relay side,
buzz_admission_rejections_total{transport="websocket",reason="quota"}climbs while the user is only reading and occasionally sending.Closest existing report is #7019 (closed as not planned), where the desktop composer hung for the same reason before the rejection was made correlatable.