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

invoices/sql_store: switch to targeted queries, default timestamp bounds

Public commit record

What the developer wrote

Authored by ziggie

73/100 · Adequate
invoices/sql_store: switch to targeted queries, default timestamp bounds

Replace all four FilterInvoices call sites with the focused queries
introduced in the previous commit:

FetchPendingInvoices → FetchPendingInvoices
InvoicesSettledSince → FilterInvoicesBySettleIndex
InvoicesAddedSince → FilterInvoicesByAddIndex
QueryInvoices → FilterInvoicesForward / FilterInvoicesReverse

The first three are straight 1:1 swaps — the new params structs carry
only the fields that are actually used, and the removed fields (Reverse,
PendingOnly, unused index bounds) were always left at their zero values.

QueryInvoices is restructured more substantially. The forward/reverse
branch now selects between FilterInvoicesForward and
FilterInvoicesReverse, each of which takes a concrete id bound that is
always set:

forward: AddIndexGet = IndexOffset + 1 (≥ 1 when IndexOffset = 0)
reverse: AddIndexLet = IndexOffset - 1 (or MaxInt64 when offset = 0)

Timestamp parameters are changed from nullable (sql.NullTime with
OR-based SQL fallbacks) to always-on Go-side defaults, consistent with
the approach used by the payments query:

createdAfter → time.Unix(0, 0).UTC() (epoch, before any invoice)
createdBefore → time.Date(9999, 12, 31, …) (far future, no upper cap)

This ensures the planner always sees plain range predicates on
created_at and can use the invoices_created_at_idx index.

The SQLInvoiceQueries interface is updated to expose the five new
methods and drop FilterInvoices.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a backend cleanup of how LND searches its invoice database. It replaces one large catch-all query with several smaller, focused queries and always supplies concrete date and index bounds. The main practical effect is better database query planning and indexing, which can improve performance and reduce load. It is not a fix for an active security vulnerability, but it removes a pattern (nullable OR-based SQL fallbacks) that can sometimes hide subtle correctness or denial-of-service risks.

Recommended action

Treat as a routine performance/hardening refactor. Include in normal review and testing, especially verifying that the new queries return identical results to the old FilterInvoices for pending, settled-since, added-since, and forward/reverse list operations. No emergency response is warranted.

Security signals we found

01

Eliminates nullable SQL parameters and OR-based fallback predicates in invoice timestamp filtering

02

Replaces catch-all FilterInvoices with targeted queries that match existing indexes

03

Potential denial-of-service risk reduction: poorly planned invoice queries could previously cause full table scans under load

04

No input validation, authentication, cryptographic, or memory-safety changes visible in the diff

Risk score

Why this scored 19/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 3/15
Confidence 8/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.