The litestar floor installs but cannot be imported #242

Activity

1. lesnik512

   added

   bugSomething isn't workingSomething isn't working

   ready-for-agentFully specified, ready for an AFK agentFully specified, ready for an AFK agent

   on Sep 20, 2026
2. lesnik512

   added a commit that references this issue on Sep 20, 2026

   test: drop FromPath so the litestar suite runs at the declared floor (#…

   ...

   b336947
3. lesnik512

   closed this as completedin #246on Sep 20, 2026
4. lesnik512 commented on Sep 20, 2026

   

   lesnik512

   on Sep 20, 2026

   MemberAuthor

   More actions

   Numbers from re-checking this at b336947, after #244 and #246 landed. Posting as data rather than to reopen — the scope call is yours, and #239 suggests it may already be deliberate.

   The two defects this issue named are fixed. The declared floors as a whole are not yet green:

   20 failed, 304 passed, 3 warnings
   

   • 15 in tests/test_litestar_bootstrap.py — the app returns 500 where the test expects 200:

     assert '/gp-default/{user_id}' in '{"status_code":500,"detail":"Internal Server Error"}'
     

   • 5 in tests/instruments/test_sentry_instrument.py:

     TypeError: LoggingIntegration.__init__() got an unexpected keyword argument 'sentry_logs_level'
     AttributeError: 'LoggingIntegration' object has no attribute '_sentry_logs_handler'
     

   The sentry signature is the one #244 set out to fix. That fix guards on the sentry-sdk version, but sentry-sdk>=2.1 resolves to 2.1.0 at the bottom, and the guard does not hold there — so the floor still names a version the instrument cannot use.

   Resolved floors in that run, for reference:

   fastapi 0.133.0   faststream 0.6.0    litestar 2.19.0   opentelemetry-api 1.28.0
   orjson 3.11.1     prometheus-client 0.20.0   sentry-sdk 2.1.0   structlog 23.2.0
   

   Reproduce

   EX=$(python -c "import tomllib;print(','.join(tomllib.load(open('pyproject.toml','rb'))['project']['optional-dependencies']))")
   uv venv --python 3.10 .venv-lowest
   VIRTUAL_ENV=.venv-lowest uv pip install --resolution lowest-direct ".[$EX]"
   VIRTUAL_ENV=.venv-lowest uv pip install pytest pytest-cov pytest-asyncio httpx2 "redis>=5.2.1" "structlog>=22.2"
   VIRTUAL_ENV=.venv-lowest python -m pytest -q

   The second install is this repo's own dev group at default resolution, deliberately — flooring the test tooling as well produces failures that look like floor problems and are not. That is a real trap here: starlette 1.6 moved TestClient to httpx2, but an older resolved starlette calls httpx.Client(app=...), removed in httpx 0.28, and every test then fails with Client.__init__() got an unexpected keyword argument 'app'. It cost me a wrong bisect elsewhere before I spotted it.

   Context

   This came out of an org-wide lower-bound audit (modern-python/.github#107): 14 of 24 repos had at least one broken floor. The other 13 are now fixed and their issues closed.

   lite-bootstrap was the one I did not attempt, because the failures cascade — a resolver stops at the first wall, so each fix only exposes the next. faststream-outbox took four rounds and three PRs (modern-python/faststream-outbox#185, modern-python/faststream-outbox#186, modern-python/faststream-outbox#187) to go green, and this repo has 28 extras rather than 5.

   Worth saying plainly: keeping litestar>=2.19 and adapting the code, as #246 did, is the better strategy where it works — it preserves support breadth instead of cutting it, which every one of my 13 fixes did by raising floors. If the remaining 20 are worth chasing, that approach is likely to carry further than raising sentry-sdk would.
5. lesnik512

   added a commit that references this issue on Sep 20, 2026

   fix(sentry): read the logentry key the installed SDK fills, and mark …

   ...

   0e37785