paymentsdb: log unexpected nil attempt hashes
What changed, and why it matters
This commit adds an error log when a piece of routing data (an HTLC attempt hash) is unexpectedly missing, so the fallback behavior is no longer silent. It is a defensive observability improvement, not a fix for an exploitable vulnerability.
No immediate action required beyond normal review and deployment. Operators should monitor logs for the new error message to detect unexpected nil attempt hashes in live router code.
Security signals we found
Defensive logging added for an invariant violation
No input validation, authorization, or cryptographic change
No memory-safety, race-condition, or remote-trigger path evident in diff
Evidence from the diff
In payments/db/sql_store.go, RegisterAttempt already falls back to the paymentHash when attempt.Hash is nil. The change adds an error log on that fallback branch. It does not change control flow, validation, or persistence logic; it only surfaces the nil-hash condition for operational visibility.
Changed components
lnd/payments/db/sql_store.goRegisterAttempt methodInspect captured patch +4 / −0
diff --git a/payments/db/sql_store.go b/payments/db/sql_store.go
index 6454ab4..3d92385 100644
--- a/payments/db/sql_store.go
+++ b/payments/db/sql_store.go
@@ -1477,6 +1477,10 @@ func (s *SQLStore) RegisterAttempt(ctx context.Context,
attemptHash := paymentHash[:]
if attempt.Hash != nil {
attemptHash = attempt.Hash[:]
+ } else {
+ log.Errorf("RegisterAttempt: attempt %d has nil hash, "+
+ "falling back to payment identifier %x",
+ attempt.AttemptID, paymentHash)
}
_, err = db.InsertHtlcAttempt(ctx, sqlc.InsertHtlcAttemptParams{
Why this scored 17/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.