AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 18 Bitcoin

Stop storing channel errors in `AuditDb` (#3236)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

98/100 · Strong
Stop storing channel errors in `AuditDb` (#3236)

We stop storing every `ChannelErrorOccured` event in the `AuditDb`.
This is very spammy because there are a lot of non-fatal events,
and they turned out to be unnecessary for auditing (they make more
sense in the logs for debugging).

Such events include for example notifying that we tried to relay a
payment to a channel that didn't have enough balance, or commands
sent to channels that are offline, closing or reconnecting.

Note that we stop creating the corresponding table, but we don't
delete old data: it is up to node operators to decide whether they
want to keep it or not. We still support migrating older databases
including data from this table.

We also remove tests from very old migrations (more than 2 years old)
which are spammy but not very interesting anymore.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit removes a database table that was used to store routine, mostly non-serious channel error events. It is a cleanup change: the events are still logged to normal log files, but they are no longer written to the audit database. There is no indication this fixes a security vulnerability; it is described by the project as a way to reduce database noise and storage use.

Recommended action

No security action required. Operators who relied on the audit database for channel error history should note that new events will only be available in application logs after this change. Reviewers may confirm that the removed table is not referenced elsewhere and that the retained metrics still meet operational needs.

Security signals we found

01

No security-relevant signals in commit message or diff

02

Data retention change: stops writing new channel error records to audit DB

03

Existing data not deleted; migration support preserved

04

Log message converted from string interpolation to structured logging (minor, not a security fix)

Risk score

Why this scored 18/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 1/15
Affected reach 2/15
Confidence 9/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.