Celery, max_length and Django 1.8 #3424
Description
I've found an interesting bug in one of our projects. When we run Celery using celery -A appname worker we get:
File "...transactions.py", line 10, in <module>
class TransactionSerializer(serializers.ModelSerializer):
File "...transactions.py", line 26, in TransactionSerializer
reference = serializers.CharField(max_length=20)
File "/venv/local/lib/python2.7/site-packages/rest_framework/fields.py", line 675, in __init__
message = self.error_messages['max_length'].format(max_length=self.max_length)
File "/venv/local/lib/python2.7/site-packages/django/utils/functional.py", line 136, in __wrapper__
res = func(*self.__args, **self.__kw)
File "/venv/local/lib/python2.7/site-packages/django/utils/translation/__init__.py", line 84, in ugettext
return _trans.ugettext(message)
File "/venv/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 327, in ugettext
return do_translate(message, 'ugettext')
File "/venv/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 304, in do_translate
_default = _default or translation(settings.LANGUAGE_CODE)
File "/venv/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 206, in translation
_translations[language] = DjangoTranslation(language)
File "/venv/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 116, in __init__
self._add_installed_apps_translations()
File "/venv/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 164, in _add_installed_apps_translations
"The translation infrastructure cannot be initialized before the "
django.core.exceptions.AppRegistryNotReady: The translation infrastructure cannot be initialized before the apps registry is ready. Check that you don't make non-lazy gettext calls at import time.It only appears when running Celery (runserver is perfectly fine) and it's not consistent. For context, we have 2 configurations running from this code-base - the configuration that uses these modules (via Celery) actually runs perfectly fine. The configuration that doesn't use this module is the one that reports this traceback.
It can be worked around by removing max_length from the field definition. This may actually be a bug in Celery but it does manifest inside DRF so I'm posting here to get any comments on whether the fix can be made here.
Let me know if you need any more clarification or tests running.