Description
As discussed in #8205 (thanks @sentrivana).
With async SQLAlchemy, DB spans never get query source (code.function, code.filepath, …), because add_source never finds an application frame.
SQLAlchemy's asyncio extension runs the sync driver inside a greenlet that it starts from the coroutine awaiting the query. The cursor events that create the span run in that greenlet. Walking f_back from there reaches only SQLAlchemy and greenlet frames, then stops at the greenlet's boundary, so it never sees the application code that issued the query.
When the current greenlet is SQLAlchemy's bridge, add_source now continues into the parent greenlet's suspended frames, which hold the awaiting coroutine. Other greenlets aren't followed, since a greenlet's parent isn't necessarily its caller and following it could attribute the span to unrelated code. It only reads frames, and it does nothing if greenlet isn't imported or the lookup fails.
The bridge is recognised by __sqlalchemy_greenlet_provider__, the attribute SQLAlchemy checks itself, which it sets from 1.4.53 and 2.0.31. Earlier releases don't set it, so there it is recognised by its class, _AsyncIoGreenlet from a sqlalchemy module. I checked both paths locally against 1.4.52 and 2.0.30, where the test fails without the class check.
The test runs a query through SQLAlchemy's real greenlet_spawn from a coroutine and checks the coroutine is its source, for both static and streamed spans; it fails on master.
It skips only before SQLAlchemy 1.4, not when greenlet is missing, so it fails instead of silently not running if greenlet ever drops out of the 1.4+ environments.
greenlet is only an optional extra of SQLAlchemy 2.x, and 1.4 installs it only on some platforms (not macOS arm64), so I added it to the 1.4+ test environments in scripts/populate_tox/config.py. In tox.ini I applied only the lines the generator adds for it, leaving out the 2.1.6 → 2.1.8 bump it would also make, to keep this PR scoped. Happy to commit the full regeneration instead if you prefer; a full run currently also bumps most other integrations.
With the reproduction from the issue (SQLAlchemy 2.1.6, aiosqlite):
master: SELECT 1 -> None
this PR: SELECT 1 -> async_query
Issues
Written with Claude (Opus 5.5). I reviewed the change and ran the reproduction and the SQLAlchemy 1.2, 1.4, 2.0 and 2.1 test suites locally before opening this.