Yes, that's probably the best short-term fix and will keep it working with
older versions - I'll put that in as a fix for this now.
I agree it's potentially dangerous, but then I also think the current
behaviour is a bit misleading. I'll dig around some third party apps and
see if I can see exampl
The change you proposed might be acceptable, although I'm a bit nervous
about breaking backwards-compatibility in some unforeseen use case. I
wonder if modifying the condition in the
channel_session decorator to: if session.modified and not
session.is_empty(): would solve the issue? This seems s
Here's the Channels issue underlying it:
https://github.com/django/channels/issues/477
For quick reference, the @channel_session decorator is something that wraps
a consumer, loading a session on the way in and saving it on the way out if
it changed, similar to how session middleware might work.
I'm not sure offhand. Could you provide a link to the issue so we could
look at the details?
On Monday, January 23, 2017 at 1:45:48 PM UTC-5, Andrew Godwin wrote:
>
> An interesting bug has turned up in Channels where someone is trying to
> remove a session using .flush(), but our decorator sees
An interesting bug has turned up in Channels where someone is trying to
remove a session using .flush(), but our decorator sees that it's been
modified and then re-saves it, thinking it needs to persist data.
What are people's opinions on changing flush() to also set modified=False
on sessions? Is
