Since this was written, we now test if remote side would get into this situation and stop
it from happening, so the test doesn't work any more.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can still get a warning:
lightningd-1 2025-12-10T01:11:07.232Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-connectd: Received WIRE_WARNING: WARNING: channel_announcement: no unspent txout 109x1x1
This has nothing to do with l1 talking about the original channel
(which would be 103x1x): it's because l2's gossipd (being the node
which does the splice) immediately forgets the pre-splice id. If l1
sends some gossip, it will get a warning message.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We used to just run these without valgrind, but we already run them in
CI (which sets SLOW_MACHINE) without valgrind, so this just doubles
up.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
```
common/test/run-param.c:381:8: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior common/test/run-param.c:381:8
```
Probably because CI now on 24.04, so more recent clang. But the test really does
want to see what happens when the callback is NULL, so workaround.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When paying through a direct channel, direct_pay_override() creates a
route bypassing the normal routing path, which skips the CLTV budget
check in payment_getroute(). This allows payments to succeed even when
maxdelay is set below the required min_final_cltv_expiry.
Add a check in direct_pay_override() to verify the required CLTV
doesn't exceed cltv_budget before using the direct channel shortcut.
If it exceeds, skip the direct channel and let normal routing handle
the failure with a proper error message.
Fixes: #8609
Changelog-Fixed: pay: `maxdelay` parameter now enforced for direct channel payments
gossipd no longer makes gossip messages, and hasn't since v24.02, so it
doesn't actually need to talk to the hsm daemon.
Also, various comments were out of date, so fix those too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- ReadMe API v2 now requires category.uri instead of category.id.
- ReadMe v2 page responses include a renderable field indicating whether the document is MDX-compatible and can be rendered successfully. The script now checks this field and prints detailed compilation errors if rendering fails.
We had the test backwards, so we moved it *all the time*. This bloats our gossip store, as well as
not moving it in the case where we need to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: gossipd: we would occasionally not show a node announcement in listnodes().
Remove anyhow as a dependency from the tlv module. This allows for a
cleaner error handling
Changelog-None
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
The core module shouldn't depend on anything from the cln_adapters
module. This ensures that we can switch out interfaces in the future
(e.g a different database than cln's datastore).
This change made it necessary to refactor the service plugin which
allowed us to clean it up on the go
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Separate concerns of the lsps2 modules into their respective layers:
core for tlv, as it is lightning related, not specifically
core-lightning. cln_adapters for core-lightning related types.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit separates the business logic from core-lighting behaviour
and moves the core-lightning related implementations into the
cln_adapters module.
Splits up tests as well
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This now only makes it easier to test, but also more modular. It allows
us to use any kind of storage, not only the datastore.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
The ClnApi trait is way overloaded. We break things down to make it more
modular on the service side.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We replace the legacy transport by a slim custommsg hook that makes use
of the lightweight multiplexed transport and avoids deserialization and
serialization through this extra layer
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We can separate concerns here by adding a lightweight multiplexing
transport client. This helps us to clean up any direct dependencies on
CLN
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit replaces the lsps service. Therefore we add the cln_adapters
module that handles the communication with core-lightning. We add a
lightweight LspsService that wraps the router and allows handlers to
register themselves to the service/router.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This router is very lightweight and can handle routing for the lsps
service. It avoids allocations by just borrowing from the request. This
is much cleaner than what we have now and reduces the amount of
serializations by a lot.
Also it supports typed handlers which will remove serialization overhead
from the handlers in future commits
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
There is no need to communicate via a generic JsonRpcClient if all
messages are well defined and we can use the typed transport to remove a
whole lot of overhead and just pass the ResponseObjects directly to the
Transport layer
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Introducing "request" to the transport trait that uses the RequestObject
and JsonRpcResponse directly reduces some overhead and unnecessary
conversions. Why do we implement a generic transport over &str when we
already know that we are dealing with JSON-RPC 2.0 here.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
There is no need to generate the id in some client when we can actually
generate it on a lower layer as we know by LSPS0 how we have to generate
it.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
