django / django/channels

Specification: nix `group_expiry` setting (or at least, 1-day default)

Open
#1,371 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.