We don't do this yet, so we add deprecated to those test (until next
patch!).
Changelog-Deprecated: plugins: `commando` JSON commands without an `id` (see doc/lightningd-rpc.7.md for how to construct a good id field).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The top of the file indicates the following errors:
#define NO_ERROR 0
#define ERROR_FROM_LIGHTNINGD 1
#define ERROR_TALKING_TO_LIGHTNINGD 2
#define ERROR_USAGE 3
But we didn't use the right one for opt_parse failure, and didn't use the
correct constants everywhere.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This avoids any confusion between primitive and string ids, and in
particular stops an issue with commando once it starts chaining ids,
that weird ids can be double-escaped and commando will not recognize
the response, leaving the client hanging. It's the client's fault for
using a weird id, but it's still rude (and triggered by our tests!).
It also makes substituting the id in passthrough simpler, FTW.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When called with `"id": 1` we replied with `"id": "1"`. lightningd doesn't
actually care, but it's weird.
Copy the entire token: this way we don't have to special case anything.
Also, remove the doubled test in json_add_jsonstr.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Issue #5363 documented an earlier bug in mkfunding. These tests validate that fix as well as checking that basic usage produces the proper response and exit status.
Changelog-None
When a channel is not yet confirmed onchain and only has an alias,
`getroute` will return the alias under the "channel" key. However, if
you supply that to `sendpay`, it will not be able to find the channel
and will fail since it calls `find_channel_for_htlc_add` and that only
looks for channels by their scid and doesn't consider their alias.
This patch makes `find_channel_for_htlc_add` also consider channel
aliases when looking for channels.
Changelog-Fixed: JSON-RPC: `sendpay` now can send to a short-channel-id alias for the first hop.
local_connected allocates a struct node_map off of the struct
listchannels_opts but fails to ever release the internal table, so those
table allocations hang around forever. Add node_map_clear as a
destructor for the struct node_map to ensure that the internal table is
freed when the enclosing struct is freed.
Changelog-Fixed: topology: Fixed memleak in `listchannels`
Signed-off-by: Matt Whitlock <c-lightning@mattwhitlock.name>
We were stressing the servers if node cannot be found. Only do lookup
on manual connect commands.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Protocol: lightningd: Only use DNS server address lookup on manual `connect` commands, not normal reconnection attempts.
I discovered this while reworking the CI workflow, and it seems like
the HTLC queries do not order, while the tests assume a specific
order. This matches sqlite3 which without an explicit ORDER clause
will use insertion order, while postgres does not keep things in
insertion order, thus breaking the assumption. Ordering by `id`
re-establishes that implicit assumption
Changelog-Changed: postgres: Ordering of HTLCs in `listhtlcs` are now ordered by time of creation
This often helps the msat purge and pyln msat replacement mischmasch issues.
I changed it in a way that the `AttributeError: 'int' object has no attribute 'millisatoshis'`
Error will still be raised whever a `Millisatoshi` is compared to
something else then a `Millisatoshi` or `int`.
Changelog-None
There are several cases where you want to access to the configuration,
and given the nature of the rust API, there is no way to access to
the `configuration` field at any point after the configuration logic.
Suggested-by: Sergi Delgado Segura <@sr-gi>
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
```
error: failed to run custom build command for `cln-grpc v0.1.2 (/home/rusty/devel/cvs/lightning/cln-grpc)`
Caused by:
process didn't exit successfully: `/home/rusty/devel/cvs/lightning/target/debug/build/cln-grpc-933c4bf5006f522c/build-script-build` (exit status: 101)
--- stdout
cargo:rerun-if-changed=proto/node.proto
cargo:rerun-if-changed=proto
--- stderr
thread 'main' panicked at 'Could not find `protoc` installation and this build crate cannot proceed without
this knowledge. If `protoc` is installed and this crate had trouble finding
it, you can set the `PROTOC` environment variable with the specific path to your
installed `protoc` binary.If you're on debian, try `apt-get install protobuf-compiler` or download it from https://github.com/protocolbuffers/protobuf/releases
For more information: https://docs.rs/prost-build/#sourcing-protoc
', /home/rusty/.cargo/registry/src/github.com-1ecc6299db9ec823/prost-build-0.11.4/src/lib.rs:1296:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
make: *** [plugins/Makefile:211: target/debug/examples/cln-plugin-startup] Error 101
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We used to install it only when Rust was configured, but for some
reason all builds now seem to be Rust builds. That's ok, so just
provide the necessary dependency.
We will likely re-add that dependency later as a feature (to
automatically provide an RPC instance if compiled with that feature)
but for now that dependency is unused.
Changelog-None Not user visible
This commit updates outdated dependencies and hangs all
bitcoin-related dependencies off of the `bitcoin` crate, using its
re-exports. This means that as long as the bitcoin crate matches, all
of its dependents will also match.
Changelog-None
Rusty Russell
Gregg Zigler
tony-voltage
Justin Litchfield
dependabot[bot]
Dennis Reimann
Simon Vrouwe
arowser
tony
ekzyis
Christian Decker
Jesse de Wit
Carl Dong
Matt Whitlock
Michael Schmoock
w0xlt
Vincenzo Palazzo
Greg Sanders
Sergi Delgado Segura