fix: Guarante at most once delivery

[danidee10]

Addresses #299

This library (aioredlock) Implements the redis distributed locking algorithm redlock

This should create a distributed lock that prevents other consumers from receiving the message if it has already been picked up

[danidee10]

I realized that this aioredlock isn't actively maintained anymore and I'm switching to pottery

[carltongibson]

Hi @danidee10.

This isn't something I'd be looking to add directly to channels_redis.

It would make a great blog post to begin and then maybe a third party package. Very happy to link to such from the channels docs.

[danidee10]

Oh. I didn't see any reply in the linked issue (i.e #299) and I assumed it was just waiting for someone to pick it up :)

But then it leaves an unanswered question about the Channels spec.

This is a quote from the channels documentation:

only a single reader should get each written message. Implementations must never deliver a message more than once or to more than one reader, and must drop messages if this is necessary to achieve this restriction.

The new pub/sub layer doesn't follow this if you have multiple listeners on the same channel (For example via python manage.py runworker).

I think the documentation needs to be updated If this isn't the case anymore. no ?

[carltongibson]

Yes, potentially. I'm not totally sure what I think about the issue. I read the spec as saying "delivery isn't guaranteed" -- ie not at least once -- rather than implying that the channel layer should enforce at most once. I appreciate the latter reading is available but it seems a little silly.

Certainly the docs could have a small note added about the possibility of more than once delivery.

[danidee10]

I think the confusing parts are:

only a single reader should get each written message

... or to more than one reader

I would just remove both statements and rewrite it from:

only a single reader should get each written message. Implementations must never deliver a message more than once or to more than one reader, and must drop messages if this is necessary to achieve this restriction.

To this

Implementations must never deliver a message more than once and must drop messages if this is necessary to achieve this restriction.

and then add a Note to users in the workers documentation:

Channels doesn't guarantee exactly once delivery/processing. Running multiple workers on the same channel will result in all workers receiving the same message.

What do you think ?