[Triage] ASGI worker ignores configured keepalive with Django ASGI apps (closes idle connections immediately)

[josema-xyz]

Type

Bug Report

Description

The native asgi worker does not honor the configured keepalive when serving a Django ASGI application: it closes idle keep-alive connections immediately after the response, with no Connection: close header.

The same worker, same version, same config keeps connections alive for the full keepalive duration when serving a bare ASGI app. Only swapping the app for Django's get_asgi_application() (no database, no middleware) triggers the early close. The control socket confirms the value is loaded (keepalive: 30), so it is read but not applied for these connections.

Behind a load balancer that pools and reuses upstream connections (e.g. an AWS ALB with a 60s+ idle timeout), the balancer reuses a socket the worker has already closed and returns 502s that never reach the application. Running the same Django app under the uvicorn worker (which honors its own keep-alive timeout) makes it go away.

Steps to Reproduce (for bugs)

Minimal, no DB and no middleware. keepalive = 30, one worker.

app_bare.py

async def app(scope, receive, send):
    assert scope["type"] == "http"
    await send({"type": "http.response.start", "status": 200,
                "headers": [(b"content-type", b"text/plain")]})
    await send({"type": "http.response.body", "body": b"ok"})

app_django.py

from django.conf import settings
from django.http import HttpResponse
from django.urls import path

settings.configure(DEBUG=True, SECRET_KEY="x", ALLOWED_HOSTS=["*"],
                   ROOT_URLCONF=__name__, MIDDLEWARE=[])

def index(request):
    return HttpResponse("ok")

urlpatterns = [path("", index)]

from django.core.asgi import get_asgi_application
app = get_asgi_application()

test.py (sends one request, then times how long the idle connection stays open)

import socket, time
s = socket.create_connection(("127.0.0.1", 8000), timeout=60)
s.sendall(b"GET / HTTP/1.1\r\nHost: x\r\n\r\n")
print("resp1 status:", s.recv(8192).split(b"\r\n", 1)[0].decode())
t0 = time.monotonic()
while s.recv(1):
    pass
print(f"server closed the idle connection after {time.monotonic() - t0:.2f}s")

Steps:

1. gunicorn -c config.py app_bare:app, then python test.py -> connection held ~30s (correct).
2. gunicorn -c config.py app_django:app, then python test.py -> connection closed at ~0.00s (bug).
3. For comparison, run app_django under worker_class = "uvicorn_worker.UvicornWorker" with timeout_keep_alive = 30 -> held ~30s (works).

Configuration

# config.py
bind = "127.0.0.1:8000"
workers = 1
worker_class = "asgi"
keepalive = 30

# run
gunicorn -c config.py app_bare:app      # held ~30s
gunicorn -c config.py app_django:app    # closed ~0.00s

# the value is loaded correctly:
gunicornc -c "show config" | grep keepalive   # -> keepalive: 30

Logs / Error Output

# bare ASGI app (app_bare:app)
resp1 status: HTTP/1.1 200 OK
server closed the idle connection after 30.01s

# Django ASGI app (app_django:app), same worker and config
resp1 status: HTTP/1.1 200 OK
server closed the idle connection after 0.00s

Gunicorn Version

gunicorn (version 26.0.0)

Python Version

Python 3.12.12

Worker Class

asgi (beta)

Operating System

macOS 15, also on Docker with Debian bookworm (python:3.12-slim)

Additional Context

Behavior matrix (idle connection held vs configured keepalive = 30):

app	asgi worker	gunicorn + uvicorn worker
bare ASGI	held ~30s	held ~30s
Django ASGI	closed 0.00s	held ~30s

• Bare ASGI on the asgi worker is fine, so this looks specific to the interaction between Django's ASGIHandler and the native worker's keep-alive handling.
• No Connection: close header is sent, so a fronting load balancer keeps the connection pooled and reuses a closed socket -> ELB 502s with no target log entry.
• Workaround: switch to the uvicorn worker (uvicorn-worker) with timeout_keep_alive set; keep-alive then behaves as configured.

Checklist

• I have searched existing discussions and issues for duplicates
• I have checked the documentation and FAQ