askrene: remove max_deliverable cache from increase_flows.
What changed, and why it matters
This is a small internal code cleanup in Core Lightning's payment routing plugin (askrene). It removes a precomputed cache of maximum deliverable amounts and instead calculates those values on demand. There is no indication this fixes a security bug or changes externally observable behavior.
No security action required. Treat as routine refactoring.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit refactors increase_flows() in plugins/askrene/refine.c to drop the max_deliverable array parameter and instead call flow_max_deliverable(rq, flow, NULL) inside the function. The caller refine_flows() no longer precomputes and stores max_deliverable for each flow. The functional behavior appears equivalent: the same cap is still applied, just computed on demand. The change is framed as preparation for future reuse of increase_flows() from other call sites.
Changed components
plugins/askrene/refine.cInspect captured patch +6 / −11
diff --git a/plugins/askrene/refine.c b/plugins/askrene/refine.c
index 64ce3221..4e5e8705 100644
--- a/plugins/askrene/refine.c
+++ b/plugins/askrene/refine.c
@@ -389,11 +389,11 @@ static struct amount_msat remove_excess(struct flow **flows,
* flow beyond the tolerance fraction. It doesn't increase any flow above its
* max_deliverable value.
* Returns the total delivery amount. */
-static struct amount_msat increase_flows(struct flow **flows,
+static struct amount_msat increase_flows(const struct route_query *rq,
+ struct flow **flows,
size_t **flows_index,
struct amount_msat deliver,
- double tolerance,
- struct amount_msat *max_deliverable)
+ double tolerance)
{
if (tal_count(flows) == 0)
return AMOUNT_MSAT(0);
@@ -422,7 +422,7 @@ static struct amount_msat increase_flows(struct flow **flows,
can_add = amount_msat_min(can_add, amt);
/* no more than max_deliverable */
- if (!amount_msat_sub(&amt, max_deliverable[index],
+ if (!amount_msat_sub(&amt, flow_max_deliverable(rq, flow, NULL),
flow->delivers))
continue;
else
@@ -461,19 +461,15 @@ const char *refine_flows(const tal_t *ctx, struct route_query *rq,
{
const tal_t *working_ctx = tal(ctx, tal_t);
const char *error_message = NULL;
- struct amount_msat *max_deliverable;
struct amount_msat *min_deliverable;
size_t *flows_index;
- max_deliverable = tal_arrz(working_ctx, struct amount_msat,
- tal_count(*flows));
min_deliverable = tal_arrz(working_ctx, struct amount_msat,
tal_count(*flows));
flows_index = tal_arrz(working_ctx, size_t, tal_count(*flows));
for (size_t i = 0; i < tal_count(*flows); i++) {
// FIXME: does flow_max_deliverable work for a single
// channel with 0 fees?
- max_deliverable[i] = flow_max_deliverable(rq, (*flows)[i], bottleneck_idx);
min_deliverable[i] = flow_min_deliverable(rq, (*flows)[i]);
/* We use an array of indexes to keep track of the order
* of the flows. Likewise flows can be removed by simply
@@ -485,15 +481,14 @@ const char *refine_flows(const tal_t *ctx, struct route_query *rq,
for (size_t i = 0; i < tal_count(flows_index); i++) {
(*flows)[flows_index[i]]->delivers =
amount_msat_min((*flows)[flows_index[i]]->delivers,
- max_deliverable[flows_index[i]]);
+ flow_max_deliverable(rq, (*flows)[flows_index[i]], bottleneck_idx));
}
/* remove excess from MCF granularity if any */
remove_excess(*flows, &flows_index, deliver);
/* increase flows if necessary to meet the target */
- increase_flows(*flows, &flows_index, deliver, /* tolerance = */ 0.02,
- max_deliverable);
+ increase_flows(rq, *flows, &flows_index, deliver, /* tolerance = */ 0.02);
/* detect htlc_min violations */
for (size_t i = 0; i < tal_count(flows_index);) {
Why this scored 11/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.