What the developer wrote
Authored by ziggie
channeldb: rename paymentSeqMx
What changed, and why it matters
This commit simply renames an internal mutex variable from paymentSeqMx to seqMu. It is a non-functional code cleanup with no behavior change and no security relevance.
No action needed; this is a benign refactor.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff changes only the identifier of a sync.Mutex field in KVPaymentsDB and updates its two references in nextPaymentSequence(). There are no logic, locking, or API changes. The mutex still protects the same currPaymentSeq/storedPaymentSeq fields in the same way.
Changed components
channeldb/payments_kv_store.goInspect captured patch +3 / −3
diff --git a/channeldb/payments_kv_store.go b/channeldb/payments_kv_store.go
index 5474f60..703297a 100644
--- a/channeldb/payments_kv_store.go
+++ b/channeldb/payments_kv_store.go
@@ -120,7 +120,7 @@ var (
// KVPaymentsDB implements persistence for payments and payment attempts.
type KVPaymentsDB struct {
// Sequence management for the kv store.
- paymentSeqMx sync.Mutex
+ seqMu sync.Mutex
currPaymentSeq uint64
storedPaymentSeq uint64
@@ -757,8 +757,8 @@ func fetchPaymentBucketUpdate(tx kvdb.RwTx, paymentHash lntypes.Hash) (
// nextPaymentSequence returns the next sequence number to store for a new
// payment.
func (p *KVPaymentsDB) nextPaymentSequence() ([]byte, error) {
- p.paymentSeqMx.Lock()
- defer p.paymentSeqMx.Unlock()
+ p.seqMu.Lock()
+ defer p.seqMu.Unlock()
// Set a new upper bound in the DB every 1000 payments to avoid
// conflicts on the sequence when using etcd.
Why this scored 15/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.