Django container shows StreamingHttpResponse related warning in production

[acyment]

On my production server I get four times the following warning:

/usr/local/lib/python3.12/site-packages/django/http/response.py:517: Warning: StreamingHttpResponse must consume synchronous iterators in order to serve them asynchronously. Use an asynchronous iterator instead.

I searched for the string StreamingHttpResponse in the repository and couldn't find it, so I guess it is being triggered by a package. According to Gemini 2.0 Flash this could have a non-trivial performance hit (couldn't find a reliable source to back the statement). django-browser-reload uses StreamingHttpResponse, but again, although there is mention to the project in past discussions, I couldn't find any reference to django-browser-reload in the current code.

Anyone has any idea whether this merits digging into and, if so, where it might stem from?

Thanks!
Alan

[browniebroke]

That rings a bell... Took me a moment to find the issue I was thinking of: #5196. That seems different though, as it's in local development, not production, like you.

Few questions to help track down the problem:

1. Are you hitting this on some specific routes/pages or mostly everywhere?
2. Are you on a fairly vanilla setup from cookiecutter Djano or did you add a lot more to your generated templates? Especially in terms of 3rd party apps and Django version (the template is still on 5.0)
3. Options used to generate your project: are you using async? DRF? Docker? Heroku?

I found this forum post by using a good old DDG search, it has a few pointers of things you could try. I would encourage you to contribute to that thread if you find a solution, as it may get more eyes on it that this repo's discussions.

[acyment]

Hi!

1. It's basically a SPA with just a couple of anchors, so basically this shows when serving to the page
2. I added a lot in terms of React code. In terms of apps, I only added django-mjml & django-money to base.txt
3. DRF + Docker => yes | Heroku => No | Async => Honestly, I can't remember what I chose (I am not sure what answering "yes" implies 😳

According to the thread you mention, it is hard to track and it shouldn't affect performance that bad. Hopefully whatever external code I use that might be causing it will solve the problem in a future version🤷🏻‍♂️

Using the -W error flag as mentioned in the thread didn't help much

Thanks!

[browniebroke]

Can you check the compose/production/django/start script? It's what is run when the container starts and has 2 optiosn depending on your answer to using async:

cookiecutter-django/{{cookiecutter.project_slug}}/compose/production/django/start

Lines 30 to 34 in 6b8545a

	{%- if cookiecutter.use_async == 'y' %}
	exec /usr/local/bin/gunicorn config.asgi --bind 0.0.0.0:5000 --chdir=/app -k uvicorn_worker.UvicornWorker
	{%- else %}
	exec /usr/local/bin/gunicorn config.wsgi --bind 0.0.0.0:5000 --chdir=/app
	{%- endif %}

If the command uses uvicorn worker (-k uvicorn_worker.UvicornWorker), you run in an async context with ASGI (config.asgi), and that's probably why you're seeting this.