AsyncTestClient session data is not being set/not accessible from app middleware

[smac89]

I'm trying to test something in my codebase. This is the test I have written:

from contextlib import aclosing, suppress
from threading import Thread

import pytest
from fakeredis import TcpFakeServer
from litestar import Litestar
from litestar.testing import AsyncTestClient
from sqlalchemy.exc import InvalidRequestError
from sqlalchemy.ext.asyncio import AsyncSession
from sqlalchemy.orm import Session
from sqlalchemy.orm.exc import ObjectDeletedError

from app.db import app_db_config
from app.models import Devices, Organizations, OrganizationUsers, UserDevicePermissionAssociation, Users
from app.util.testutil import disable_event_listener


@pytest.fixture(autouse=True, scope="session")
def prepare_db():
    from litestar.plugins.sqlalchemy import AlembicCommands

    alembic_commands = AlembicCommands(sqlalchemy_config=app_db_config)
    alembic_commands.upgrade()


@pytest.fixture(autouse=True)
def redis_server():
    server = TcpFakeServer(("127.0.0.1", 6381), server_type="redis")
    th = Thread(target=server.serve_forever, daemon=True)
    th.start()
    yield

    server.shutdown()
    server.server_close()
    th.join()


@pytest.fixture
async def client():
    from app import app, session_config

    async with AsyncTestClient(
        app,
        session_config=session_config,
        # https://anyio.readthedocs.io/en/stable/basics.html#backend-specific-options
        backend_options={"use_uvloop": True},
    ) as client:
        app.debug = True
        app.state.is_test_mode = True
        yield client
        app.debug = False
        app.state.is_test_mode = False


@pytest.fixture
async def db_session():
    session_maker = app_db_config.create_session_maker()
    db_objs = []
    async with aclosing(session_maker()) as session:
        session.info["is_test_mode"] = True
        yield session
        for obj in session.identity_map.values():
            with suppress(InvalidRequestError):
                await session.refresh(obj)
                db_objs.append(obj)

    async with app_db_config.get_session() as session:
        for obj in db_objs:
            with suppress(ObjectDeletedError):
                if obj not in session.deleted:
                    await session.delete(obj)

        await session.commit()


async def test_get_devices_returns_users_devices(client: AsyncTestClient[Litestar], db_session: AsyncSession):
    from app.models.users import create_cognito_user_on_user_create_or_delete

    with disable_event_listener(Session, "before_flush", create_cognito_user_on_user_create_or_delete):
        user = Users(name="test", email="user@testemail.com", username="test_user")
        org = Organizations(name="test_org", s3_bucket="test_bucket", s3_region="test_region")
        db_session.add_all([user, org])
        await db_session.flush()

        devices = (Devices(name="device-01", organization_id=org.id), Devices(name="device-02", organization_id=org.id))
        db_session.add_all(devices)
        await db_session.flush()

        user_org = OrganizationUsers(user_id=user.id, organization_id=org.id)
        user_devices = [UserDevicePermissionAssociation(user_id=user.id, device_id=d.id, read=True) for d in devices]
        db_session.add_all([user_org, *user_devices])
        await db_session.flush()

        # !! problematic code !!
        await client.set_session_data({"user_id": user.id, "access_token": "1", "id_token": "1"})

        await db_session.commit()
        await db_session.refresh(user)

        response = await client.get("/devices")
        assert response.status_code == 200

When I run the test above, the request fails with 500 error code. The output shows:

RuntimeError: Task <Task pending name='anyio.from_thread.BlockingPortal._call_func' coro=<BlockingPortal._call_func() running at /home/user/Development/webapp/server/.venv/lib/python3.13/site-packages/anyio/from_thread.py:259> cb=[TaskGroup._spawn.<locals>.task_done() at /home/user/Development/webapp/server/.venv/lib/python3.13/site-packages/anyio/_backends/_asyncio.py:805]> got Future <Future pending> attached to a different loop
INFO:   [2026-01-15 16:57:23 httpx] HTTP Request: GET http://testserver.local/devices "HTTP/1.1 500 Internal Server Error"

Very similar to #1920

Tbh, I didn't realize it was the line above that was causing this issue, but today I was trying to make the test work, and decided to replace that line with a call to blocking portal:

with client.portal() as portal:
    portal.call(client.set_session_data, {"user_id": user.id, "access_token": "1", "id_token": "1"})

To my surprise, it kinda worked! The test got past that line. However, the session data was not set. In the middleware within my app which handles authentication, it fails to read any of the attributes I set for the session.

class AppAuthMiddleware(AbstractAuthenticationMiddleware):
    scopes = {ScopeType.HTTP}

    @override
    async def authenticate_request(self, connection):
        with contextlib.suppress(ImproperlyConfiguredException, InvalidTokenError):
            user_id = cast(str | None, connection.session.get("user_id"))
            access_token = cast(str | None, connection.session.get("access_token"))
            id_token = cast(str | None, connection.session.get("id_token"))

            if not (user_id and access_token and id_token):
                raise NotAuthorizedException(detail="User is not logged in")
        ...

At this point, I'm now stuck. What am I doing wrong?

[smac89]

Just following up here. I investigated further and can confirm that after the call to client.set_session_data, the client.cookies contains a cookie called session with a value that matches what I see in the logs for the redis client:

------------------------------------------------- Captured stdout call -------------------------------------------------
session: {'user_id': 'pEoZiFPpPX2uw7xvaQxrN', 'access_token': '1', 'id_token': '1'}
client cookies: <Cookies[<Cookie session=bf357b192d4bf9737466ac300948d857503a4e03a9d8b94f2f13161eb06a9caa for testserver.local />]> headers: Headers({'accept': '*/*', 'accept-encoding': 'gzip, deflate', 'connection': 'keep-alive', 'user-agent': 'testclient'})
------------------------------------------------- Captured stderr call -------------------------------------------------
DEBUG:  [2026-01-16 10:42:24 fakeredis] +++ 127.0.0.1 connected
DEBUG:  [2026-01-16 10:42:24 fakeredis] >>> 127.0.0.1: [b'CLIENT', b'SETINFO', b'LIB-NAME', b'redis-py']
DEBUG:  [2026-01-16 10:42:24 fakeredis] <<< 127.0.0.1: b'OK'
DEBUG:  [2026-01-16 10:42:24 fakeredis] >>> 127.0.0.1: [b'CLIENT', b'SETINFO', b'LIB-VER', b'6.2.0']
DEBUG:  [2026-01-16 10:42:24 fakeredis] <<< 127.0.0.1: b'OK'
DEBUG:  [2026-01-16 10:42:24 fakeredis] >>> 127.0.0.1: [b'SET', b'LITESTAR_sessions:bf357b192d4bf9737466ac300948d857503a4e03a9d8b94f2f13161eb06a9caa', b'{"user_id":"pEoZiFPpPX2uw7xvaQxrN","access_token":"1","id_token":"1"}', b'EX', b'3600']
DEBUG:  [2026-01-16 10:42:24 fakeredis] <<< 127.0.0.1: b'OK'
...

This leads me to believe that the problem is that the client is not even sending the cookie along when the request is sent.

[smac89]

I think I discovered the problem. session_config is defined as:

session_config = ServerSideSessionConfig(
    ..., secure=True, ...
)

The problem seems to arise from the fact that I set secure=True, which means the cookie is not available in non https contexts. By changing the base_url of the TestClient to https://testserver.local, the session data is now available in the middleware.

[smac89]

Despite having discovered a solution, I still want to point out that the initial problem that plagued this line is still there, and needs to be investigated:

# !! problematic code !!
await client.set_session_data({"user_id": user.id, "access_token": "1", "id_token": "1"})

[euri10]

hello @smac89 , the AsyncTestClient was rewritten in #4291 to be async-first and I have the gut feeling this may solve your issue, is it possible (not sure you get tons of breakage or not since you'd upgrade a major) for you to check if you get the same issue on main ?

[smac89]

@euri10 unfortunately, I wasn't able to get the dependencies working in a reliable enough way for the tests to run.

[euri10]

alright you'll have to do it for upgrading to 3. when it comes out, but well, let's try differently :)

if you can come up with a mcve someone else could run that is great, it's rather hard to reproduce and it may be already fixed,

From having experienced the pain debugging this BlockingPortal issue I noticed this: what are you using to run async tests, anyio or pytest-asyncio ? what pytest version ? reason I'm asking is that I see you get a mix of sync and async fixtures which pytest now should warn you about, see pytest-dev/pytest#12930 and agronholm/anyio#789, and probably agronholm/anyio#803 contains stuff you can compare to your case.

[smac89]

@euri10

I use pytest-asyncio for running the tests.

In my pyproject.toml file, I have the following:

[tool.pytest.ini_options]
# https://pytest-asyncio.readthedocs.io/en/latest/concepts.html#test-discovery-modes
asyncio_mode = "auto"                          # or "strict"
asyncio_default_fixture_loop_scope = "session"
asyncio_default_test_loop_scope = "session"

My test dependencies:

[project.optional-dependencies]
test = [
    "fakeredis==2.33.0",
    "pytest==9.0.2",
    "pytest-asyncio==1.3.0",
]

I can try for sometime this week to come up with an MVCE

[euri10]

@euri10

I use pytest-asyncio for running the tests.

In my pyproject.toml file, I have the following:

[tool.pytest.ini_options]
# https://pytest-asyncio.readthedocs.io/en/latest/concepts.html#test-discovery-modes
asyncio_mode = "auto"                          # or "strict"
asyncio_default_fixture_loop_scope = "session"
asyncio_default_test_loop_scope = "session"

My test dependencies:

[project.optional-dependencies]
test = [
    "fakeredis==2.33.0",
    "pytest==9.0.2",
    "pytest-asyncio==1.3.0",
]

I can try for sometime this week to come up with an MVCE

alright then I dont see anything obvious and the reproducer will be helpful.

side note, you said:

@euri10 unfortunately, I wasn't able to get the dependencies working in a reliable enough way for the tests to run.

maybe we can help here, yes there will be breaking changes if you switch to main but afaik there shouldn't be any issues with dependencies now.