#1558·guardrails

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

python
# 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

python
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: 0

Proposed Fix

Indent self.db.execute(...) inside the if block.

PR

#1556

Source: guardrails-ai/guardrails