Specification: nix `group_expiry` setting (or at least, 1-day default)
- Dominant language
- Python
- Stars
- 6.4k
- Forks
- 826
- PR merge metrics
- No merged PRs in 30d
Description
I maintain https://github.com/CJWorkbench/channels_rabbitmq.
I propose nixing `group_expiry` from the Channel Layer specification. It should be an option specific to the Redis layer.
Redis has a global store of group memberships. When Daphne dies, the membership info remains in a Redis data structure -- it has "leaked." `channels_redis` can't delete _leaked_ group memberships (by definition); so it deletes _expired_ group memberships instead, as a proxy. From what I can tell, "expiry" was invented to handle "leaked memberships." By default, a membership "expires" one day after creation, according to the spec.
I also surmise from some Googling that `group_expiry` can sometimes defend the Redis layer against full buffers -- that's django/channels_redis#384, and `group_expiry` doesn't solve it in general.
`channels_rabbitmq` doesn't have "leaked memberships." Memberships are subscriptions, and they're stored as part of the Daphne-RabbitMQ ASGI connection. If Daphne dies, RabbitMQ cleans up the subscriptions.
And `channels_rabbitmq` defends against full buffers more sensibly: it gives each message a TTL, and it warns when dropping old messages. If the user forgets to `group_discard()`, the warning highlights the problem, and old messages don't pollute the buffer so a production server stays up.
The upshot: with `channels_rabbitmq`, `group_expiry` does no good. It only solves problems inherent to the Redis layer.
`group_expiry` certainly does _harm_. It stalls Websocket connections that are older than a day -- by default.
With the Redis layer, the `group_expiry` feature and default do more good than harm. With the Channels layer, the `group_expiry` does no good -- only harm.
Please remove `group_expiry` from the Channel Layer Specification. It belongs in the Redis layer only.
Contributor guide
Research direction
Locate the Channel Layer Specification and all references to group_expiry, then compare the Redis and RabbitMQ behavior described in the issue. Done means the specification no longer requires this setting, or the proposed one-day default is addressed with the layer-specific rationale documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, rabbitmq, redis
- Domain
- backend-api-design, distributed-systems
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100