Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

xpay treats a local "Too many HTLCs" failure as a 1 msat capacity shortfall and floods the route with dust parts.

オープン
  • 何か問題がありますか？
#9,597 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
65/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c
領域
backend, networking, payments

調査の方向性

Start by tracing the local failure path in plugins/xpay/xpay.c at the handling and askrene-inform-channel calls, then compare it with channeld/channeld.c and channeld/full_channel.c. Check how plugins/askrene/askrene.c records constrained amounts. Done means a local "Too many HTLCs" failure no longer causes repeated amount-minus-1-msat retries and dust-part creation; verify the behavior with the relevant existing test or reproduction.

索引モデルが issue の本文から書いたものです。

説明

When our own outgoing channel has no free HTLC slots, channeld fails the HTLC with temporary_channel_failure ("Too many HTLCs"). xpay handles that like a liquidity failure and tells askrene the channel is constrained to the attempted amount. askrene stores that as "amount minus 1 msat". The same channel stays the cheapest route, so the next getroutes sends the big part over it again, 1 msat smaller, and routes the 1 msat leftover elsewhere. Each retry fails again on the full slots, so xpay produces one new 1–17 msat part per failure. A slot shortage doesn't depend on the amount, so this loop can never succeed.

Observed (mainnet, v26.06.8)

Payment of 298,495 sat, retry_for 60 s:

  • From the first "Too many HTLCs" on our own channel (erring_index 0), xpay ran this cycle 98 times in 14
    s, about once every 60 ms.
  • The dust parts summed to 237 msat. They went over other channels, reached the destination, and were held
    there for about 2 minutes until mpp_timeout.
  • The main part (~295.5k sat) never left our node, so the payment failed.

xpay log (ids shortened):

      260: routes for 295521663msat = [1msat via 4 hops, 295521662msat via 2 hops]
      260: ...: We got failed: WIRE_TEMPORARY_CHANNEL_FAILURE (WIRE_TEMPORARY_CHANNEL_FAILURE: Too many HTLCs)
  for <local scidd>, assuming it can't carry 295521662msat
      260: routes for 295521662msat = [1msat via 4 hops, 295521661msat via 2 hops]
      260: ...: We got failed: WIRE_TEMPORARY_CHANNEL_FAILURE (... Too many HTLCs) for <local scidd>, assuming
  it can't carry 295521661msat
      ... (98 iterations)
      260: getroutes_done: need more (was_routing 295521655msat, needs_routing 295521656msat)

According to my LLM:

Where it happens
  1. channeld reports a full slot count as a generic temporary_channel_failure:
    channeld/channeld.c#L6602-L6605. The count check, including our own limit applied to
    locally added HTLCs: channeld/full_channel.c#L728-L740
  2. For a local failure (index == 0), xpay has the precise reason ("Too many HTLCs") in the error message:
    plugins/xpay/xpay.c#L1008-L1013
  3. It still maps every temporary_channel_failure to "can't carry this amount":
    plugins/xpay/xpay.c#L1125-L1131
    and sends askrene-inform-channel with inform: constrained and the attempted amount:
    plugins/xpay/xpay.c#L1181-L1193
  4. askrene turns that into a maximum of amount − 1 msat ("we were one msat short"):
    plugins/askrene/askrene.c#L1199-L1211
主要言語
C
スター
3.1k
フォーク
1k
平均マージ
3日 10時間
マージ済み PR（30日）
40

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ElementsProject/lightning のほかの issue

ElementsProject/lightning の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。