Swaps gets stuck on pending

[Arshia-r-m]

I faced strange problem testing rapid swaps, after some points, swaps got stuck on PENDING state, the maker execute returned 200, but swaps never succeed/expired/failed.

From this I can assume the RLN never marks the swaps that are in pending state as expired even the expiry time has passed, I'll open a fix PR for this.

I also tried to find out why the swaps were stuck on pending and not failing/succeeding, but up to now I didn't find any thing, so can you please help me on this one? (probably could be an edge case)
I attached the directory of taker and maker both below, this happened on 2026-04-13 if you want to check.

Keep in mind that in between you are going to see some failed ones, pending stuck starts before, I don't think they are relevant.

[Arshia-r-m]

I just check and swaps in pending will expire after 24h, but shouldn't they also expire after the expiry?
Let me know what you think

[Arshia-r-m]

Since the file is over 25MB, I have uploaded it here

[Arshia-r-m]

Update:
I probably have found the problem, the maker failed the payment with retry exhausted, and marked the payment as failed, but on the taker side, the Event::HTLCHandlingFailed has not been properly handled.

[zoedberg]

When listing swaps, those in the waiting status move to an expired status if the expiration passed, those in the pending status move to a failed status if they are still pending after 24h after initiation time.
The /makerexecute API checks the expiration to be sure the expiration time set in the swapstring hasn't passed, if so it updates the status to expired.
The /taker API fails if the swapstring expiry time passed.
If the /makerexecute API succeeds the swap goes to a pending status.
On the taker side the swap goes from the waiting status to a failed or succeeded status.
To me this seems the correct behavior, the expiration is a way for the maker to say "let's not initiate the swap after this time", so it's not an expiration tied up to the completion time but to the initiation time. IMO the parties should not interrupt the swap because it took time from when it started and when it completed (especially since, in case of swaps with multi-hop routes, collaboration across different parties is required and could take time).
Do you think swap expiration handling should change?

Would you please write a test that reproduces the problem you found?

[Arshia-r-m]

What actually happened is that we have multiple swaps that are marked as failed on the maker side but pending on the taker side.

I took a deeper look to the logs, this is the flow that caused this:

• Maker starts the swap payment and sends an HTLC to the taker.
• Taker receives and intercepts the HTLC.
• Taker validates that the HTLC matches a whitelisted swap.
• Taker marks its local swap status as Pending.
• Taker tries to forward the intercepted HTLC to the next hop.
• Forwarding fails on the taker side because the outgoing RGB HTLC limit is 0.
• Maker receives the payment failure.
• Maker marks its swap as Failed.
• Taker receives/emits HTLCHandlingFailed, but it has been ignored.

This shows two problem:

1. When taker fails to forward the HTLC, the maker receives the PaymentPathFailed, so later on marks the swap as failed, but on taker, HTLCHandlingFailed but it has been ignored, causing the swap to remain as PENDING on taker side.
2. Second one is that when calling the list swap, I believed that it should also check the pending swaps to mark them as expired, but you mentioned a good point(multi-hop routes).

But still the first one is a problem, let me know what do you think about it.

[zoedberg]

I agree missing logic in HTLCHandlingFailed seems a bug, but I think we should first prove the bug and then write a fix. Could you please add a test that reproduces the problem?