fix: add a AsyncTestClientTransport for the AsyncTestClient

[euri10]

Description

Closes

fixes #1920

[codecov]

Codecov Report

Attention: Patch coverage is 85.71429% with 4 lines in your changes missing coverage. Please review.

Project coverage is 98.35%. Comparing base (6225a82) to head (4dffcb5).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
litestar/testing/transport.py	85.18%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4142      +/-   ##
==========================================
- Coverage   98.37%   98.35%   -0.02%     
==========================================
  Files         348      348              
  Lines       15845    15861      +16     
  Branches     1749     1750       +1     
==========================================
+ Hits        15587    15600      +13     
- Misses        123      127       +4     
+ Partials      135      134       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

Documentation preview will be available shortly at https://litestar-org.github.io/litestar-docs-preview/4142

[euri10]

any idea how to cover this ? I dont understand why it pops now though

[provinzkraut]

This should even be the same loop with different client instances, right?

[euri10]

i think so, this added test is just the mcve from the issue and it fails before the changes, is there something I should add ?

[euri10]

I realize the diff is overly complicate, the PR is simple: before AsyncTestClient used TestClientTransport hence the issue.
so I created a BaseClientTransport that essentially takes care of request/response and added a ASGITestClientTransport that inherits httpx ASGIBaseTransport and overrides handle_async_request while TestClientTransport overrides handle_request, the BaseClientTransport is what's common between the 2 transports.

[provinzkraut]

i think so, this added test is just the mcve from the issue and it fails before the changes, is there something I should add ?

Yeah, maybe a test for the transport in particular that shows the client always uses the currently running loop?

[euri10]

actually if this test was using TestClient instead of AsyncTestClient it wouldn't pass as start_blocking_portal creates a new event loop.

This should even be the same loop with different client instances, right?

by different client instances you meant a AsyncTestClient and a TestClient ?

[provinzkraut]

No I mean different instances AsyncClient. But actually, I think the test should probably just show that the client uses the running loop from the context it's created in.

[provinzkraut]

With this refactoring done, I think you actually don't even need 2 transports. The sync version could just do

with self.client.portal() as portal:
    return portal.call(self.handle_async_request, request)

[euri10]

the benefit of having 2 transports is that they respectively inherit their httpx counterparts so I think it's a little bit more mypy friendly but I may be wrong

[provinzkraut]

Okay, that makes sense. Maybe could still move the request handling fn into the common base class?

[provinzkraut]

I don't think the behaviour is fully fixed yet, as the LifespanHandler still uses a portal.

async def test_lifespan_loop() -> None:
    mock = MagicMock()

    @contextlib.asynccontextmanager
    async def lifespan(app: Litestar) -> AsyncGenerator[None, None]:
        mock(asyncio.get_running_loop())
        yield

    app = Litestar(lifespan=[lifespan])

    async with AsyncTestClient(app):
        pass

    mock.assert_called_once_with(asyncio.get_running_loop())