Bug: DELETE query in _truncate runs on every call, bypassing TIME_BETWEEN_CLEANUPS throttle
Author: C0d3N1nja97342Created Jul 6, 2026Updated Sep 4, 2026
LabelsStale
Bug: DELETE query in _truncate runs on every call, bypassing the TIME_BETWEEN_CLEANUPS throttle
Problem
SQLiteTraceHandler._truncate (guardrails/call_tracing/sqlite_trace_handler.py) has a DELETE statement outside the TIME_BETWEEN_CLEANUPS if-block. Only self.last_cleanup = now is inside the if; the self.db.execute("DELETE ...") is at the same indentation as the if — so it runs on every _truncate call.
This means every log(), log_entry(), or log_validator() call triggers a DELETE query, creating unnecessary write load on every guard validation.
Root Cause
# guardrails/call_tracing/sqlite_trace_handler.py, _truncate()
if force or (now - self.last_cleanup > TIME_BETWEEN_CLEANUPS):
self.last_cleanup = now
self.db.execute("DELETE FROM guard_logs WHERE ...") # ← outside the if!The self.db.execute(...) should be indented inside the if block.
Reproduce
from unittest.mock import MagicMock
from guardrails.call_tracing.sqlite_trace_handler import SQLiteTraceHandler
handler = SQLiteTraceHandler("/tmp/test.db", read_mode=False)
handler.db = MagicMock()
# Immediately after init, last_cleanup = time.time(), so interval has NOT elapsed
handler._truncate() # should be throttled
print(handler.db.execute.call_count)
# Bug: 1 (DELETE ran despite throttle)
# Expected: 0Proposed Fix
Indent self.db.execute(...) inside the if block.
PR
#1556
Source: guardrails-ai/guardrails