Skip to content

Update asgiref to 3.12.1 - #310

Open
pyup-bot wants to merge 1 commit into
masterfrom
pyup-update-asgiref-3.5.2-to-3.12.1
Open

Update asgiref to 3.12.1#310
pyup-bot wants to merge 1 commit into
masterfrom
pyup-update-asgiref-3.5.2-to-3.12.1

Conversation

@pyup-bot

Copy link
Copy Markdown
Collaborator

This PR updates asgiref from 3.5.2 to 3.12.1.

Changelog

3.12.1

-------------------

* Restored the previous SyncToAsync.__call__ internal code shape, which was
relied on by some APM services. (572)

Note, this change was available whilst maintaining the underlying fix (from
564). It does not constitute an API stability promise. Ideally APMs are
*not* monkey patching internal APIs, and future changes will be made here if
needed.

3.12.0

-------------------

* ``AsyncToSync`` no longer captures the running event loop on
instantiation. (562)

This resolves a series of deadlocks that users experienced after asgiref 3.9.0,
particularly with pytest-asyncio. pytest-asyncio stops the event loop between
tests, and long-running unawaited futures could find themselves trying to
schedule work onto a stopped loop, and so would never complete. Ideally, code
should be structured to await long-running futures before returning, but this
change should help users experiencing issues here.

The loop is now resolved when the callable is invoked rather than when it is
created. If ``async_to_sync`` is called from within ``sync_to_async``, the
parent event loop is still used, as before.

The possibility of deadlock therefore remains in some nested patterns. For
example, an async function may call a long-running ``sync_to_async`` function
that itself uses ``async_to_sync``; if the outer function returns before the
sync future completes, the parent event loop may already be stopped, and the
nested calls cannot be driven to completion.

This is not a bug in asgiref — the same patterns deadlock in plain asyncio. As
above, restructure your code to await the ``sync_to_async`` future before
exiting the driving coroutine.

* Fixed an event loop deadlock when exiting ``ThreadSensitiveContext``
while its executor thread was still blocked waiting on the event loop.
(535)

* Dropped support for EOL Python 3.9.

* Fixed ``StatelessServer.run()`` failing on Python 3.14, where
``asyncio.get_event_loop()`` no longer creates an event loop if none
exists. It now uses ``asyncio.run()``. (559)

* Fixed ``Local`` leaking data between unrelated sync threads when
``sys.flags.thread_inherit_context`` is enabled (Python 3.14+), so a newly
started thread inherits a copy of the spawning thread's context. This flag is
on by default on free-threaded builds and opt-in on the regular GIL build.
``Local`` storage is now tagged with its owning thread and re-homed only when
asgiref intentionally moves work across threads (in ``async_to_sync`` /
``sync_to_async``), restoring the documented thread-local behaviour in sync
threads.

* asgiref is now tested against the free-threaded builds of Python 3.13 and
3.14 in CI.

* The ``tests`` extra no longer installs ``mypy``; a new ``mypy`` extra is
available for type-checking the codebase.

3.11.1

-------------------

* SECURITY FIX CVE-2025-14550: There was a potential DoS vector for users of
the ``asgiref.wsgi.WsgiToAsgi`` adapter. Malicious requests, including an unreasonably
large number of values for the same header, could lead to resource exhaustion
when building the WSGI environment.

To mitigate this, the algorithm is changed to be more efficient, and
``WsgiToAsgi`` gains a new optional ``duplicate_header_limit`` parameter,
which defaults to 100. This specifies the number of times a single header may
be repeated before the request is rejected as malformed.

You may override ``duplicate_header_limit`` when configuring your application::

   application = WsgiToAsgi(wsgi_app, duplicate_header_limit=200)

Set ``duplicate_header_limit=None`` if you wish to disable this check.

* Fixed a regression in 3.11.0 in ``sync_to_async`` when wrapping a callable
with an attribute named ``context``. (537)

3.11.0

-------------------

* ``sync_to_async`` gains a ``context`` parameter, similar to those for
``asyncio.create_task``, ``TaskGroup`` &co, that can be used on Python 3.11+ to
control the context used by the underlying task.

The parent context is already propagated by default but the additional
control is useful if multiple ``sync_to_async`` calls need to share the same
context, e.g. when used with ``asyncio.gather()``.

3.10.0

-------------------

* Added AsyncSingleThreadContext context manager to ensure multiple AsyncToSync
invocations use the same thread. (511)

3.9.2

------------------

* Adds support for Python 3.14.

* Fixes wsgi.errors file descriptor in WsgiToAsgi adapter.

3.9.1

------------------

* Fixed deletion of Local values affecting other contexts. (523)

* Skip CPython specific garbage collection test on pypy. (521)

3.9.0

------------------

* Adds support for Python 3.13.

* Drops support for (end-of-life) Python 3.8.

* Fixes an error with conflicting kwargs between AsyncToSync and the wrapped
function. (471)

* Fixes Local isolation between asyncio Tasks. (478)

* Fixes a reference cycle in Local (508)

* Fixes a deadlock in CurrentThreadExecutor with nested async_to_sync →
sync_to_async → async_to_sync → create_task calls. (494)

* The ApplicationCommunicator testing utility will now return the task result
if it's already completed on send_input and receive_nothing. You may need to
catch (e.g.) the asyncio.exceptions.CancelledError if sending messages to
already finished consumers in your tests. (505)

3.8.1

------------------

* Fixes a regression in 3.8.0 affecting nested task cancellation inside
sync_to_async.

3.8.0

------------------

* Adds support for Python 3.12.

* Drops support for (end-of-life) Python 3.7.

* Fixes task cancellation propagation to subtasks when using synchronous Django
middleware.

* Allows nesting ``sync_to_async`` via ``asyncio.wait_for``.

* Corrects WSGI adapter handling of root path.

* Handles case where `"client"` is ``None`` in WsgiToAsgi adapter.

3.7.2

------------------

* The type annotations for SyncToAsync and AsyncToSync have been changed to
more accurately reflect the kind of callables they return.

3.7.1

------------------

* On Python 3.10 and below, the version of the "typing_extensions" package
is now constrained to be at least version 4 (as we depend on functionality
in that version and above)

3.7.0

------------------

* Contextvars are now required for the implementation of `sync` as Python 3.6
is now no longer a supported version.

* sync_to_async and async_to_sync now pass-through

* Debug and Lifespan State extensions have resulted in a typing change for some
request and response types. This change should be backwards-compatible.

* ``asgiref`` frames will now be hidden in Django tracebacks by default.

* Raw performance and garbage collection improvements in Local, SyncToAsync,
and AsyncToSync.

3.6.0

------------------

* Two new functions are added to the ``asgiref.sync`` module: ``iscoroutinefunction()``
and ``markcoroutinefunction()``.

Python 3.12 deprecates ``asyncio.iscoroutinefunction()`` as an alias for
``inspect.iscoroutinefunction()``, whilst also removing the ``_is_coroutine`` marker.
The latter is replaced with the ``inspect.markcoroutinefunction`` decorator.

The new ``asgiref.sync`` functions are compatibility shims for these
functions that can be used until Python 3.12 is the minimum supported
version.

**Note** that these functions are considered **beta**, and as such, whilst
not likely, are subject to change in a point release, until the final release
of Python 3.12. They are included in ``asgiref`` now so that they can be
adopted by Django 4.2, in preparation for support of Python 3.12.

* The ``loop`` argument to ``asgiref.timeout.timeout`` is deprecated. As per other
``asyncio`` based APIs, the running event loop is used by default. Note that
``asyncio`` provides timeout utilities from Python 3.11, and these should be
preferred where available.

* Support for the ``ASGI_THREADS`` environment variable, used by
``SyncToAsync``, is removed. In general, a running event-loop is not
available to `asgiref` at import time, and so the default thread pool
executor cannot be configured. Protocol servers, or applications, should set
the default executor as required when configuring the event loop at
application startup.
Links

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant