askrene: clamp impression-adjusted min/max to channel capacity
Maintainer thường phản hồi trong vòng 2 ngày
@Lagrang3 đang làm issue này rồi.
Từ ngày 4/8/2026.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
Follow-up from #9150.
layer_apply_constraints() applies impressions without bounding the result:
- reverse direction:
minandmaxboth grow byimp->amount, saturating atUINT64_MAX, with no clamp to the channel's gossmap capacity - forward direction: both shrink by
imp->amount, saturating at 0
Since #9150, get_constraints() seeds *max from gossmap_chan_get_capacity() instead of -1ULL, so reverse-direction impressions can push max above the channel's real capacity, and enough forward-direction volume drives max to 0 and makes askrene treat a live channel as dead.
The FIXME added to test_xpay_fake_channeld in that PR documents the symptom:
/* FIXME: We fail on #10, due mainly to a buildup of usage on 0x2134x0/0:
* Failed: We could not find a usable set of paths. The shortest path is
* 103x1x0->0x2134x0->1725x11x1725, but 0x2134x0/0 exceeds htlc_maximum_msat ~1000448msat
*/
Bounded in practice by two things: mcf.c defensively does if (min > max) min = max, and xpay calls askrene-age with a one-hour cutoff before every payment, so impressions expire. But the layer state is still incoherent in the meantime, and explain_failure.c documents an invariant (total >= max_capacity_known >= known_usable) that impressions can violate, since max can exceed cap_msat.
Minimum fix: clamp max to the channel capacity and min to max inside layer_apply_constraints().
Broader question, raised by Lagrang3 during review: the magnitude by which impressions move the bars is too aggressive. A successful payment proves liquidity of at least amount existed, so subtracting the full amount from max discards information rather than adding it. Worth revisiting the model alongside the clamp.
- Ngôn ngữ chính
- C
- Star
- 3.1k
- Fork
- 1k
- Merge trung bình
- 4 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 45
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ElementsProject/lightning
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
ElementsProject/lightning#9593 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
ElementsProject/lightning#9322 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
ElementsProject/lightning#9206 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
ElementsProject/lightning#9187 · 1 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 2 ngày
-
QA
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
ElementsProject/lightning#9117 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của ElementsProject/lightning
Issue tương tự
-
rc_runtime_activate_richpresence leaves a half-initialised entry when the buffer allocation failsĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
RetroAchievements/rcheevos#558 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
libsdl-org/SDL#16464 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
chore(gateway): emit INFO budget reserved/settled logs for proactivity v2 (chip task_2855f4ec)Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởbackend
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
BasedHardware/omi#20940 ·
Maintainer thường phản hồi trong vòng 1 ngày