It was only ever expermental, so I don't feel bad about just removing it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Removed: JSON-RPC: `sendonionmessage` (was experimental only, use `injectonionmessage`)
Making sure that we are able to fetch the invoice
from an offer without description
E pyln.client.lightning.RpcError: RPC call failed: method:
offer, payload: {'amount': '2msat'}, error: {'code': -32602, 'message':
'bolt12: Offer does not contain a description: invalid token
\'"lno1qgsqvgnwgcg35z6ee2h3yczraddm72xrfua9uve2rlrm9deu7xyfzrcgqyppvggz953rvg9rtxj8lalh43z8epwydjfrmffn3y3p5qz5cywpu09rr4vs"\''}
Link: https://github.com/ElementsProject/lightning/issues/7405
Link: https://github.com/ElementsProject/lightning/issues/7404
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
We never call `listconfigs` in our tests with `experimental-offers` enabled,
so we didn't notice that the schema is wrong: it does not expect the
"plugin" field in 'fetchinvoice-noconnect'.
The next patch folds the fetchinvoice plugin into the offers plugin,
which is enabled even if `experimental-offers` isn't (for `decode`),
so we notice it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Somehow, this documentation got lost during the Great Rewrite, so
restore that too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: JSON-RPC: `offer` removed `@` prefix support from `recurrence_base` (use `recurrence_start_any_period` set to `false`)
The schema in the docs for the `ConnectNotification` was faulty.
I've already fix this in https://github.com/ElementsProject/lightning/pull/7085
The new schema is
```
{
"connect" : {
"address" : {
"address" : "127.0.0.1",
"port" : 38012,
"type" : "ipv4"
},
"direction" : "in",
"id" : "022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59"
}
}
```
The `address` in the `connect` field will be encoded in protobuf as
`ConnectAddress`. However, this collides with the `ConnectAddress` that
is defined in the `connect` rpc-method.
This commit
- Updates the schema in `doc/schemas/notification/connect.json`
- Changes `msggen` to include an override to `PeerConnect` for any
notification typename that starts with `Connect`
Both have an `address` field which is a composite type. This results in
naming collisions
schema's: Updated schema for connect-notification
schema for connect notification + overrides
Override ConnectAddress to `PeerConnectAddress` in protobuf
for notifications
**Problem Description**
In previous commits I introduced some new fields to `msggen`.
One example is `CustomMsgResponse` in `cln-grpc/src/notification.rs`.
```rust
pub struct CustomMsgResponse {
#[serde(skip_serializing_if = "Option::is_none")]
pub peer_id: Option<PublicKey>,
#[serde(skip_serializing_if = "Option::is_none")]
pub payload: Option<String>,
}
```
The `peer_id` and `payload` are required parameters.
However, the generated code is still marking them as `Optional`.
This is a choice made by `msggen`. It does this because `payload` and
`peer_id` are recently added fields. By marking the field as optional
the language bindings would also work when used on an older version of
Core-Lightning.
In this scenario. Marking them as optional is overkill.
The `CustomMsgStruct` and `payload` field are created in the same
version of CoreLightning.
This commit solves this behavior.
We don't actually support it yet, but this threads through the type change,
puts it in "decode" etc.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Updated config params and plugin
- Updated documentation
Changelog-Added: Added a new configuration for clnrest plugin to change the default Swagger UI path from `/` to custom url.
