fix(audit): do not record-audit engine bookkeeping updates #43

2026-10-15T12:46:24Z

KofTwentyTwo commented

2026-10-15 12:46:24 +00:00

(Migrated from github.com)

Problem

On kof22 production, alerts_monitor and alerts_alert were the second and third largest audit sources after 2026-10-15 (6 hours: 7,189 monitor audits, 2,030 alert audits). Field breakdown (read-only aggregate on prod):

table	fields	audits (6h)
alerts_monitor	no details (header only)	4,962
alerts_monitor	claimedBy + claimedUntil (lease claim)	2,226
alerts_monitor	lastRunAt, nextRunAt, lastElapsedMs (run result)	~1,090
alerts_monitor	lastStatus, lastValue, lastError, consecutiveFailures	16
alerts_alert	timedNotificationCheckedAt (reminder check)	1,767
alerts_alert	no details	168
alerts_alert	occurrenceCount, lastRaisedAt (re-raise)	~80 (kept)

All by the system user: the scheduler's lease claim and run result on every monitor pass, and the reminder check on every open alert.

Change

RuntimeFields: the engine bookkeeping fields per table (monitor lease and last-run fields, conditionSince; alert timedNotificationCheckedAt, lastNotifiedAt, recordRefCount).
AlertsDb.update sets UpdateInput.withOmitDmlAudit(true) only when the update record carries nothing but those fields (plus id and modifyDate). Any update that also changes configuration or alert state (status, severity, ack, assignment, enabled, name, raise counts) is audited in full. UI and API edits do not go through AlertsDb and are audited as before.

Core has no field-level audit exclusion, so this is decided per update in the qbit.

Tests

RuntimeFieldsAuditTest: three evaluation and reminder passes write no monitor edit audits and no alert bookkeeping details. A rename, an enable/disable and an acknowledgement are still audited. It fails without the fix. ./mvnw verify: 227 tests, green.

Labelled release:rc to cut the next RC.

🤖 Generated with Claude Code

## Problem On kof22 production, `alerts_monitor` and `alerts_alert` were the second and third largest audit sources after 2026-10-15 (6 hours: 7,189 monitor audits, 2,030 alert audits). Field breakdown (read-only aggregate on prod): | table | fields | audits (6h) | |---|---|---| | alerts_monitor | no details (header only) | 4,962 | | alerts_monitor | claimedBy + claimedUntil (lease claim) | 2,226 | | alerts_monitor | lastRunAt, nextRunAt, lastElapsedMs (run result) | ~1,090 | | alerts_monitor | lastStatus, lastValue, lastError, consecutiveFailures | 16 | | alerts_alert | timedNotificationCheckedAt (reminder check) | 1,767 | | alerts_alert | no details | 168 | | alerts_alert | occurrenceCount, lastRaisedAt (re-raise) | ~80 (kept) | All by the system user: the scheduler's lease claim and run result on every monitor pass, and the reminder check on every open alert. ## Change - `RuntimeFields`: the engine bookkeeping fields per table (monitor lease and last-run fields, `conditionSince`; alert `timedNotificationCheckedAt`, `lastNotifiedAt`, `recordRefCount`). - `AlertsDb.update` sets `UpdateInput.withOmitDmlAudit(true)` only when the update record carries nothing but those fields (plus `id` and `modifyDate`). Any update that also changes configuration or alert state (status, severity, ack, assignment, enabled, name, raise counts) is audited in full. UI and API edits do not go through `AlertsDb` and are audited as before. Core has no field-level audit exclusion, so this is decided per update in the qbit. ## Tests `RuntimeFieldsAuditTest`: three evaluation and reminder passes write no monitor edit audits and no alert bookkeeping details. A rename, an enable/disable and an acknowledgement are still audited. It fails without the fix. `./mvnw verify`: 227 tests, green. Labelled `release:rc` to cut the next RC. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QRun-IO/qbit-alerts#43