Exception when using daphne / runworker about channels

[andrewgodwin]

What are your locale settings like in your project settings? I can't reproduce this locally quite yet, but it's something about the locale framework.

[andrewgodwin]

It would be great if you could see what django.utils.translation.get_language() returns from a manage.py shell. Does it definitely work when channels is uninstalled?

[orokusaki]

@andrewgodwin here it is (same result with a fresh project from django-admin.py startproject):

In [1]: from django.utils.translation import get_language
In [2]: get_language() is None
Out[2]: True

My settings are:

LANGUAGE_CODE = 'en-us'
USE_I18N = True

The URL (/admin/jsi18n/) works with Django's runserver ('channels' not in INSTALLED_APPS).

I was just digging through Django's translation code, because this makes no sense (neither get_language() returning None, nor the fact that this would fail only with Channels installed). I'll continue to investigate, but I wanted to post this here first.

[orokusaki]

Unless I'm misunderstanding something, based on the get_language docs, there is a Django bug (get_language should return 'en-us', according to my understanding, since I haven't disabled I18N or used override or deactivate_all).

Why this doesn't matter when Channels isn't installed, I'm not sure... I probably need more coffee and have simply misunderstood something.

[orokusaki]

Also note: this bug only occurs when using daphne spam.asgi:channel_layer and python manage.py runworker. It doesn't occur when I use python manage.py runserver (even though Channels' runserver uses daphne and runworker).

[andrewgodwin]

Oh, that's really interesting! I wonder if runworker misses a setup step that runserver has - hopefully I can repro it now.

[orokusaki]

What's interesting is Django's runserver (source) sets leave_locale_alone to True. If I duplicate this on your runworker command locally, I don't get the exception. But I'm not sure if that's just masking another problem; a bug in Django. Why should I have to tell Django to use my setting, rather than the default of overriding to 'en-us' (note: my setting, incidentally, is 'en-us'), in order for the command to function properly, and why does Django's runserver (source) use this?

[andrewgodwin]

The docstring (https://github.com/django/django/blob/a8521a2c228bd9e981dc8a2bea4e26f4544a52a7/django/core/management/base.py#L190) seems to imply it's because most management commands were doing their own things with locales directly; it's unusual that a management command runs view code (in fact, only runserver and runworker do this, so it makes sense that it's not the default).

I've implemented the flag in f1ab110 - that should fix this long-term. If you could confirm that's what you did to fix it too/that it works, that would be great.

[orokusaki]

Your exact change fixes the issue. I had to apply the change manually though, because:

The strangest thing: if I install Channels via Git (hitherto, I've been using PyPI):

pip install git+git://github.com/andrewgodwin/channels.git@f1ab1100f5d60eaacd918270368399a7020948a4

I get the following exception on every request (whether I use runserver or daphne + runworker):

Unhandled Error
Traceback (most recent call last):
  File "/Users/mva/.virtualenvs/spam/lib/python3.5/site-packages/daphne/cli.py", line 95, in run
    http_timeout=args.http_timeout,
  File "/Users/mva/.virtualenvs/spam/lib/python3.5/site-packages/daphne/server.py", line 32, in run
    reactor.run(installSignalHandlers=self.signal_handlers)
  File "/Users/mva/.virtualenvs/spam/lib/python3.5/site-packages/twisted/internet/base.py", line 1194, in run
    self.mainLoop()
  File "/Users/mva/.virtualenvs/spam/lib/python3.5/site-packages/twisted/internet/base.py", line 1203, in mainLoop
    self.runUntilCurrent()
--- <exception caught here> ---
  File "/Users/mva/.virtualenvs/spam/lib/python3.5/site-packages/twisted/internet/base.py", line 825, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/Users/mva/.virtualenvs/spam/lib/python3.5/site-packages/daphne/server.py", line 52, in backend_reader
    self.factory.dispatch_reply(channel, message)
  File "/Users/mva/.virtualenvs/spam/lib/python3.5/site-packages/daphne/http_protocol.py", line 239, in dispatch_reply
    self.reply_protocols[channel].serverResponse(message)
  File "/Users/mva/.virtualenvs/spam/lib/python3.5/site-packages/daphne/http_protocol.py", line 164, in serverResponse
    self.setHeader(header.encode("utf8"), value)
builtins.AttributeError: 'bytes' object has no attribute 'encode'

[andrewgodwin]

Yup, Channels master currently also need Daphne master as the header encoding spec has changed - when I released I was going to major version bump both and mention it in the release/enforce in setup.py, but for now you just need to move to daphne master.

[orokusaki]

@andrewgodwin - thanks. I'll move to daphne@master until the next release.

[pcompassion]

I think I'm getting similar error (i'm just starting to try to use django-channels)

2016-10-20 19:14:03,160 - ERROR - server - HTTP/WS send decode error: 'bytes' object has no attribute 'encode'
[2016-10-20 19:14:03,160] ERROR (server:backend_reader_sync:99) HTTP/WS send decode error: 'bytes' object has no attribute 'encode'

I'm using django run server now.

channels==0.17.3
django 1.9.7

[andrewgodwin]

@pcompassion Please check that your daphne and asgi_redis/asgi_ipc/asgiref versions are up to date, and if so, open a new ticket with full details and traceback.

[pcompassion]

it was because I used django-rest-framework's JSONRenderer().render(), not json.dumps..