Skip to content

RuntimeError: Caught handled exception, but response already started. #292

Description

@gisce-ti-sentry

Sentry Issue: GAB-Y

ExceptionGroup: unhandled errors in a TaskGroup
  File "starlette/_utils.py", line 81, in collapse_excgroups
    yield
  File "starlette/responses.py", line 274, in __call__
    async with anyio.create_task_group() as task_group:
  File "anyio/_backends/_asyncio.py", line 799, in __aexit__
    raise BaseExceptionGroup(

OperationalError: database is locked
(5 additional frame(s) were not displayed)
...
  File "starlette/responses.py", line 277, in wrap
    await func()
  File "starlette/responses.py", line 250, in stream_response
    async for chunk in self.body_iterator:
  File "github_agent_bridge/backend.py", line 524, in _session_stream_events
    events = job_session_events(db, job_id, after_id=last_id, limit=100)
  File "github_agent_bridge/dashboard_data.py", line 504, in job_session_events
    if not table_exists(con, "job_session_events"):
  File "github_agent_bridge/dashboard_data.py", line 37, in table_exists
    row = con.execute("SELECT 1 FROM sqlite_master WHERE type='table' AND name=?", (name,)).fetchone()

RuntimeError: Caught handled exception, but response already started.
(7 additional frame(s) were not displayed)
...
  File "starlette/routing.py", line 660, in __call__
    await self.middleware_stack(scope, receive, send)
  File "starlette/routing.py", line 680, in app
    await route.handle(scope, receive, send)
  File "starlette/routing.py", line 276, in handle
    await self.app(scope, receive, send)
  File "fastapi/routing.py", line 134, in app
    await wrap_app_handling_exceptions(app, request)(scope, receive, send)
  File "starlette/_exception_handler.py", line 56, in wrapped_app
    raise RuntimeError("Caught handled exception, but response already started.") from exc

This issue was automatically created by Sentry via Github Issue

Activity

  1. giscebot commented on Oct 8, 2026

    @giscebot
    Collaborator

    Fix obert a #293.

    La causa era que SQLITE_BUSY/SQLITE_LOCKED escapava del generador SSE després d'haver començat la resposta; FastAPI ja no podia convertir l'error en un 503 i Starlette generava el RuntimeError secundari. La PR manté viu l'stream, envia el heartbeat habitual i reintenta al cicle següent exclusivament per contenció SQLite. Els errors d'esquema o d'emmagatzematge no transitoris continuen propagant-se.

    Validació: 531 tests passats, incloses regressions de recuperació de l'stream i de propagació dels errors no transitoris.

  2. giscebot commented on Oct 8, 2026

    @giscebot
    Collaborator

    PR #293 actualitzada sobre el main actual; el conflicte amb el nou boundary DashboardQueries ha quedat resolt.

    • commit: e045cc4
    • estat GitHub: mergeable
    • validació local: 5 tests SSE i suite completa, 539 passats
    • CI: dashboard, Python 3.11 i Python 3.12 en verd (run 37798783796)

    La correcció continua limitada a SQLITE_BUSY/SQLITE_LOCKED; els errors SQLite no transitoris es propaguen. PR: #293

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions