Are we expected to be able to have working ContextVars when using sync_to_async

[rtpg]

I am trying to debug an issue I'm seeing in OTel's Django Instrumentation Library, and wanted to get clarity on whether the following sort of usage of ContextVar is expected to work:

(The following fails in 3.7.2 and 3.10.0 for us)

import asyncio
from asgiref.sync import sync_to_async
from contextvars import ContextVar

currentuser = ContextVar("currentuser")

def process_request(request):
    print(f"Processing request...")
    request["reset_token"] = currentuser.set(request["username"])

def get_response(request):
    return f"Current user is {currentuser.get()}"

def process_response(request, response):
    print(f"Response was\n{response}")
    if "reset_token" in request:
        currentuser.reset(request["reset_token"])

# crashes when set to True
USE_SYNC_TO_ASYNC = True

async def main_loop():
    # set a sentinel value to confirm no leakage
    currentuser.set("<Unset>")
    request = {"username": "alice"}
    print(f"Current user is {currentuser.get()}")
    process_request(request)
    response = get_response(request)
    if USE_SYNC_TO_ASYNC:
        await sync_to_async(process_response)(request, response)
    else:
        process_response(request, response)
    print(f"Current user is {currentuser.get()}")


if __name__ == "__main__":
    result = asyncio.run(
        main_loop()
    )
    print("Done")

In the above I'm using a ContextVar to hold the currentuser (In OTel's case it's to hold tracing information). if process_response goes through sync_to_async then the token reset request fails because we're not in the same context.

My naive assumption is that Django middleware process_request and process_response would run in the same context, but it seems like there's some thread juggling going on Django-side based on logging of threading.get_native_id() that I patched into my problematic middleware, and now I'm unsure if any usage of ContextVar within the Django stack is accepted.

(asgiref.local.Local seems to work fine, though)

Anyways I'm unsure if I shouldn't expect ContextVar to work within any sync_to_async-comingled code bases. Or if this is expected to work, and isn't.

---

For more details on the OTel issue properly said, I have, in _DjangoMiddleware.process_request:

        activation = use_span(span, end_on_exit=True)
        activation.__enter__()  # pylint: disable=E1101

^ span information is held in a ContextVar. Then, over in _DjangoMiddleware.process_response:

activate.__exit__(None, None, None)

Some logging of threading.get_native_id() seems to indicate that sometimes I am ending up in different threads, and hitting an issue. It's odd to me that that this is a "sometimes" thing, but in the recent past we hit another issue around asgiref.Locals leaking due (we believe) to Django's core handler doing:

                response = await sync_to_async(
                    response_for_exception, thread_sensitive=False
                )(request, exc)

So I'm thinking that some code paths are ending up with a request's request-side middleware running in one thread, and then the response-side middleware running in another thread. Not really asking to debug that underlying issue though, if ContextVar is suspect then we probably want to swap out OTel's context management to use asgiref.Local rather than contextvars.ContextVar

[carltongibson]

Hi @rtpg — without sitting down with the debugger it's never obvious, but...

async def main_loop():
    # So we're happily in the main thread thread just blocking the event loop here: 
    process_request(request)
    response = get_response(request)

    # And here we create a thread pool and a separate called context: 
    if USE_SYNC_TO_ASYNC:
        await sync_to_async(process_response)(request, response)

But is that not this test case:

asgiref/tests/test_sync_contextvars.py

Lines 37 to 55 in f587b12

	async def test_sync_to_async_contextvars():
	"""
	Tests to make sure that contextvars from the calling context are
	present in the called context, and that any changes in the called context
	are then propagated back to the calling context.
	"""
	# Define sync function
	def sync_function():
	time.sleep(1)
	assert foo.get() == "bar"
	foo.set("baz")
	return 42
	# Ensure outermost detection works
	# Wrap it
	foo.set("bar")
	async_function = sync_to_async(sync_function)
	assert await async_function() == 42
	assert foo.get() == "baz"

[rtpg]

Yeah, that test case is showing that gets successfully work, in my example I'm calling a contextvar reset within that inner space though.

Jumping into the cpython source reset tokens are only valid used against the same context (IIRC, typing this from my phone). And here my assumption is we are stacking on new contexts for bookkeeping reasons.

Now personally there's a bit of "maybe calling a reset token should reset the var in the underlying context but not in the child context of the stack" idea (obviously a Python thing, not an asgiref thing). But well... asgiref.local.Local exists.

"Contextvars shouldn't be reset weirdly" might just be the general thing here. This is downstream of a messy usage of contextvars anyways, that I'm trying to clean up anyways

[carltongibson]

OK, I see. Yes... current status would be 🤷 — I haven't thought about this at all (or seen that usage in the wild).

I'd be happy to look at if you decide that something would be feasible here.