htlcswitch/link: ensure circuits are committed in-order
This commit makes the call to forwardBatch after locking in Adds synchronous. This ensures that circuits for any Add packets are added to the switch in the same order that they are prescribed in the channel state. Though it is very unlikely this case would arise, it may happen under more greater loads. In addition, this also makes some trivial optimizations wrt. to not spawning unnecessary goroutines if no settle/fail packets are locked in.
This commit is contained in:
parent
27ca61aedf
commit
de9de771bb
@ -1859,7 +1859,10 @@ func (l *channelLink) processRemoteSettleFails(fwdPkg *channeldb.FwdPkg,
|
||||
}
|
||||
}
|
||||
|
||||
go l.forwardBatch(switchPackets...)
|
||||
// Only spawn the task forward packets we have a non-zero number.
|
||||
if len(switchPackets) > 0 {
|
||||
go l.forwardBatch(switchPackets...)
|
||||
}
|
||||
}
|
||||
|
||||
// processRemoteAdds serially processes each of the Add payment descriptors
|
||||
@ -2365,7 +2368,12 @@ func (l *channelLink) processRemoteAdds(fwdPkg *channeldb.FwdPkg,
|
||||
|
||||
l.debugf("forwarding %d packets to switch", len(switchPackets))
|
||||
|
||||
go l.forwardBatch(switchPackets...)
|
||||
// NOTE: This call is made synchronous so that we ensure all circuits
|
||||
// are committed in the exact order that they are processed in the link.
|
||||
// Failing to do this could cause reorderings/gaps in the range of
|
||||
// opened circuits, which violates assumptions made by the circuit
|
||||
// trimming.
|
||||
l.forwardBatch(switchPackets...)
|
||||
|
||||
return needUpdate
|
||||
}
|
||||
@ -2387,7 +2395,7 @@ func (l *channelLink) forwardBatch(packets ...*htlcPacket) {
|
||||
}
|
||||
|
||||
errChan := l.cfg.ForwardPackets(filteredPkts...)
|
||||
l.handleBatchFwdErrs(errChan)
|
||||
go l.handleBatchFwdErrs(errChan)
|
||||
}
|
||||
|
||||
// handleBatchFwdErrs waits on the given errChan until it is closed, logging
|
||||
|
Loading…
Reference in New Issue
Block a user