Session close fails on an unspent channel because validate_close_amount rejects a zero-amount close

[wizrds]

Describe the bug

When a session channel is opened but nothing is spent, closing it fails. The client sends a close with cumulativeAmount of 0, and the server rejects it with:

close voucher amount must be > 0 (on-chain settled)

The channel is already funded on chain at this point, so the deposit is stuck. The normal close flow gives no way to get it back.

This happens because validate_close_amount rejects any close where cumulativeAmount <= on_chain_settled. For an untouched channel both values are 0, so a valid zero-amount close is treated as an error. A close at the already settled amount should be allowed and should just refund the remaining deposit, matching the current behavior of the TypeScript SDK mppx.

Steps to reproduce

1. Configure a server using the tempo session method with a funded close_signer.
2. From a client, open a session against a paid route. The open is folded into the first request, so the channel gets funded on chain.
3. Make that first request fail, or otherwise not get billed, so the channel's spent stays at 0.
4. Immediately send a close for the session with cumulativeAmount of 0.
5. The close is rejected with close voucher amount must be > 0 (on-chain settled).

A more direct way to see the cause is the unit level:

• Call validate_close_amount(0, 0, 0, deposit) where deposit is some positive value.
• It returns an error instead of Ok.

The repo already has a test that locks in this behavior: test_close_at_zero_rejects_when_zero_settled in src/protocol/methods/tempo/session_method.rs asserts that the zero close is rejected.

Container Type

Not running in a container

What version/commit are you on?

Discovered in v0.10.4 release on crates.io, but persists up until the latest commit as of writing 30d1128

Code of Conduct

• I agree to follow the Code of Conduct

[figtracer]

the strict > check matches the mppx fix for GHSA-mv9j-8jvg-j8mr / CVE-2026-34209

i think this issue is valid as a UX/recovery gap for an unspent opened channel but maybe adding an explicit abort/refund flow rather than relaxing cooperative close validation is safer

[wizrds]

I didn't even notice that the code I was referencing in the mppx library was actually the legacy implementation. In this case, if the correct behavior is to reject cooperative closing when the cumulative is 0, is there something clients can do today other than manually using low level machinery to request closing on chain?