OperationalError: unable to open database file

[gisce-ti-sentry]

Sentry Issue: GAB-H

OperationalError: unable to open database file
  File "threading.py", line 1024, in run
  File "github_agent_bridge/executor.py", line 233, in _loop
  File "github_agent_bridge/executor.py", line 64, in work_one
  File "github_agent_bridge/queue.py", line 155, in claim_next

This issue was automatically created by Sentry via Github Issue

[giscebot]

He comprovat que aquesta traça és la mateixa fallada corregida a #31 / #32: el procés acumulava descriptors SQLite/WAL perquè sqlite3.Connection.exit() no tanca la connexió, i acabava fallant a claim_next() amb el missatge enganyós unable to open database file.

El fix és al commit 418d166, fusionat el 25 d’agost. La nova alerta no justifica una segona correcció de codi: el commit encara no està inclòs en cap tag/release, de manera que la instància que ha generat l’alerta pot continuar executant la versió vulnerable.

Següent acció operativa: publicar/desplegar una versió que contingui 418d166 i reiniciar el servei per alliberar els descriptors ja filtrats. Mantinc l’issue obert fins confirmar la versió desplegada; després es pot tancar com a duplicat de #31.

[giscebot]

Diagnòstic corregit: gisce/github-agent-bridge és un fork i el fix de #32 havia quedat només al fork. Les releases upstream 0.60.x no el contenien; el servei amb 0.60.1 continua usant connexions SQLite normals i ara acumula 890 descriptors (510 DB + 372 WAL).

He portat el fix sobre l’upstream actual i he obert el PR principal: pilipilisbot#184 (commit 9acdf0c). Validació: 30 tests de cua i 352 tests totals passen.

Fins que el PR es fusioni i es publiqui/desplegui una release nova, reiniciar el servei només és una mitigació temporal per alliberar descriptors; no tanco l’issue encara.