Repository navigation
OperationalError: database or disk is full #344
Description
Sentry Issue: GAB-10
OperationalError: database or disk is full
(2 additional frame(s) were not displayed)
...
File "github_agent_bridge/executor.py", line 104, in _record_worker_heartbeat
self.queue.record_worker_heartbeat(
File "github_agent_bridge/queue.py", line 428, in record_worker_heartbeat
self.runtime.record_worker_heartbeat(
File "github_agent_bridge/persistence/runtime.py", line 71, in record_worker_heartbeat
with self.database.transaction(
File "contextlib.py", line 148, in __exit__
next(self.gen)
File "github_agent_bridge/persistence/database.py", line 120, in transaction
con.commit()
This issue was automatically created by Sentry via Github Issue
Reacted by GISCE Bot
Activity
giscebot commentedon Nov 11, 2026
Implemented the preventive fix in #350 (
5f18035): the monitor now measures the filesystem that contains SQLite, alerts below configurable byte/percentage thresholds, exposes the capacity metrics, and propagates settings through the systemd monitor service. Validation: 720 tests passed; a read-only check against the live database emittedmonitor.database_filesystem_lowat 2.6 GiB / 0.9% available.Operational blocker remains: this code does not reclaim host storage. The filesystem is still effectively full, so space must be freed and a clean monitor/executor observation window confirmed before treating the incident as resolved.
giscebot commentedon Nov 11, 2026
Pushed a regression-strengthening follow-up to #350: commit 88a3ab5 now proves that the capacity probe measures the resolved parent filesystem of the SQLite database, so the test would fail if monitoring drifted to the wrong mount.
Validation: 720 tests passed locally; GitHub Actions is queued for 88a3ab5: https://github.com/gisce/github-agent-bridge/actions/runs/43096761102
New operational evidence from a read-only check on the executor host: only 2,102,370,304 bytes (2.0 GiB / 0.66%) are available, down from the previously reported 2.6 GiB / 0.9%. The executor service is active, but #350 is preventive monitoring and does not reclaim storage. Host cleanup plus a clean post-cleanup observation window remain required before this incident can be considered resolved.