2021-12-04 21:53:56 +10:30
|
|
|
#include "config.h"
|
2024-01-25 08:19:20 +10:30
|
|
|
#include <ccan/cast/cast.h>
|
2022-06-19 16:49:11 +09:30
|
|
|
#include <common/configdir.h>
|
Plugin: New notification type, forward_event
`forward_event`
A notification for topic `forward_event` is sent every time the status
of a forward payment is set. The json format is same as the API
`listforwards`.
```json
{
"forward_event": {
"payment_hash": "f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2",
"in_channel": "103x2x1",
"out_channel": "103x1x1",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "settled",
"received_time": 1560696342.368,
"resolved_time": 1560696342.556
}
}
```
or
```json
{
"forward_event": {
"payment_hash": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"in_channel": "103x2x1",
"out_channel": "110x1x0",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "local_failed",
"failcode": 16392,
"failreason": "WIRE_PERMANENT_CHANNEL_FAILURE",
"received_time": 1560696343.052
}
}
```
- The status includes `offered`, `settled`, `failed` and `local_failed`,
and they are all string type in json.
- When the forward payment is valid for us, we'll set `offered`
and send the forward payment to next hop to resolve;
- When the payment forwarded by us gets paid eventually, the forward
payment will change the status from `offered` to `settled`;
- If payment fails locally(like failing to resolve locally) or the
corresponding htlc with next hop fails(like htlc timeout), we will
set the status as `local_failed`. `local_failed` may be set before
setting `offered` or after setting `offered`. In fact, from the
time we receive the htlc of the previous hop, all we can know the
cause of the failure is treated as `local_failed`. `local_failed`
only occuors locally or happens in the htlc between us and next hop;
- If `local_failed` is set before `offered`, this
means we just received htlc from the previous hop and haven't
generate htlc for next hop. In this case, the json of `forward_event`
sets the fields of `out_msatoshi`, `out_msat`,`fee` and `out_channel`
as 0;
- Note: In fact, for this case we may be not sure if this incoming
htlc represents a pay to us or a payment we need to forward.
We just simply treat all incoming failed to resolve as
`local_failed`.
- Only in `local_failed` case, json includes `failcode` and
`failreason` fields;
- `failed` means the payment forwarded by us fails in the
latter hops, and the failure isn't related to us, so we aren't
accessed to the fail reason. `failed` must be set after
`offered`.
- `failed` case doesn't include `failcode` and `failreason`
fields;
- `received_time` means when we received the htlc of this payment from
the previous peer. It will be contained into all status case;
- `resolved_time` means when the htlc of this payment between us and the
next peer was resolved. The resolved result may success or fail, so
only `settled` and `failed` case contain `resolved_time`;
- The `failcode` and `failreason` are defined in [BOLT 4][bolt4-failure-codes].
2019-06-15 21:09:09 +08:00
|
|
|
#include <lightningd/channel.h>
|
2021-12-13 16:44:32 -06:00
|
|
|
#include <lightningd/coin_mvts.h>
|
2024-01-11 16:05:46 +01:00
|
|
|
#include <lightningd/log.h>
|
2019-07-21 13:39:15 +02:00
|
|
|
#include <lightningd/notification.h>
|
2018-12-12 14:36:11 +01:00
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
bool notifications_topic_is_native(const char *topic)
|
2019-08-11 05:32:13 +08:00
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
static const char **notilist = NULL;
|
2019-08-11 05:32:13 +08:00
|
|
|
static size_t num_notis;
|
|
|
|
if (!notilist)
|
2024-01-25 08:19:20 +10:30
|
|
|
notilist = cast_const2(const char **,
|
|
|
|
autodata_get(notifications, &num_notis));
|
2019-08-11 05:32:13 +08:00
|
|
|
|
|
|
|
for (size_t i=0; i<num_notis; i++)
|
2024-01-25 08:19:20 +10:30
|
|
|
if (streq(notilist[i], topic))
|
|
|
|
return true;
|
|
|
|
return false;
|
2021-04-28 15:58:46 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
bool notifications_have_topic(const struct plugins *plugins, const char *topic)
|
|
|
|
{
|
2021-04-28 16:18:40 +02:00
|
|
|
struct plugin *plugin;
|
2021-04-28 15:58:46 +02:00
|
|
|
if (notifications_topic_is_native(topic))
|
2019-08-11 05:32:13 +08:00
|
|
|
return true;
|
|
|
|
|
2021-04-27 15:15:09 +02:00
|
|
|
/* Some plugin at some point announced it'd be emitting
|
2021-04-28 16:18:40 +02:00
|
|
|
* notifications to this topic. */
|
|
|
|
list_for_each(&plugins->plugins, plugin, list) {
|
|
|
|
for (size_t i = 0; i < tal_count(plugin->notification_topics); i++)
|
|
|
|
if (streq(plugin->notification_topics[i], topic))
|
|
|
|
return true;
|
|
|
|
}
|
2021-04-27 15:15:09 +02:00
|
|
|
|
2018-12-12 14:36:11 +01:00
|
|
|
return false;
|
|
|
|
}
|
2018-12-13 13:58:40 +01:00
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
/* Modern notifications X contain an object X */
|
|
|
|
static struct jsonrpc_notification *notify_start(const char *name)
|
|
|
|
{
|
|
|
|
struct jsonrpc_notification *n;
|
|
|
|
|
|
|
|
n = jsonrpc_notification_start(NULL, name);
|
|
|
|
json_object_start(n->stream, name);
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void notify_send(struct lightningd *ld,
|
|
|
|
struct jsonrpc_notification *n STEALS)
|
|
|
|
{
|
|
|
|
json_object_end(n->stream);
|
|
|
|
jsonrpc_notification_end(n);
|
|
|
|
plugins_notify(ld->plugins, take(n));
|
|
|
|
}
|
|
|
|
|
2023-06-27 19:24:44 -07:00
|
|
|
static void json_add_connect_fields(struct json_stream *stream,
|
2024-01-25 08:19:20 +10:30
|
|
|
const struct node_id *nodeid,
|
|
|
|
bool incoming,
|
|
|
|
const struct wireaddr_internal *addr)
|
2019-09-02 22:26:11 +08:00
|
|
|
{
|
|
|
|
json_add_node_id(stream, "id", nodeid);
|
2021-03-25 14:23:31 +10:30
|
|
|
json_add_string(stream, "direction", incoming ? "in" : "out");
|
2019-09-02 22:26:11 +08:00
|
|
|
json_add_address_internal(stream, "address", addr);
|
|
|
|
}
|
|
|
|
|
2023-06-27 19:24:44 -07:00
|
|
|
static void connect_notification_serialize(struct json_stream *stream,
|
2023-07-10 15:17:52 +09:30
|
|
|
struct lightningd *ld,
|
2023-06-27 19:24:44 -07:00
|
|
|
const struct node_id *nodeid,
|
|
|
|
bool incoming,
|
|
|
|
const struct wireaddr_internal *addr)
|
|
|
|
{
|
|
|
|
/* Old style: Add raw fields without connect key */
|
2024-01-25 10:58:55 +10:30
|
|
|
if (lightningd_deprecated_out_ok(ld, ld->deprecated_ok,
|
|
|
|
"connect_notification", "rawfields",
|
|
|
|
"v23.08", "v24.08")) {
|
2023-07-07 11:39:38 +09:30
|
|
|
json_add_connect_fields(stream, nodeid, incoming, addr);
|
2024-01-25 10:58:55 +10:30
|
|
|
}
|
2023-06-27 19:24:44 -07:00
|
|
|
json_object_start(stream, "connect");
|
|
|
|
json_add_connect_fields(stream, nodeid, incoming, addr);
|
|
|
|
json_object_end(stream);
|
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(connect);
|
2019-09-02 22:26:11 +08:00
|
|
|
|
2021-03-25 14:23:31 +10:30
|
|
|
void notify_connect(struct lightningd *ld,
|
|
|
|
const struct node_id *nodeid,
|
|
|
|
bool incoming,
|
|
|
|
const struct wireaddr_internal *addr)
|
2018-12-13 13:58:40 +01:00
|
|
|
{
|
2019-09-02 22:26:11 +08:00
|
|
|
struct jsonrpc_notification *n
|
2024-01-25 08:19:20 +10:30
|
|
|
= jsonrpc_notification_start(NULL, "connect");
|
|
|
|
connect_notification_serialize(n->stream, ld, nodeid, incoming, addr);
|
2018-12-13 13:58:40 +01:00
|
|
|
jsonrpc_notification_end(n);
|
|
|
|
plugins_notify(ld->plugins, take(n));
|
|
|
|
}
|
|
|
|
|
2023-06-27 19:26:27 -07:00
|
|
|
static void json_add_disconnect_fields(struct json_stream *stream,
|
|
|
|
const struct node_id *nodeid)
|
|
|
|
{
|
|
|
|
json_add_node_id(stream, "id", nodeid);
|
|
|
|
}
|
|
|
|
|
2019-09-02 22:28:05 +08:00
|
|
|
static void disconnect_notification_serialize(struct json_stream *stream,
|
2023-07-10 15:17:52 +09:30
|
|
|
struct lightningd *ld,
|
2024-01-25 08:19:20 +10:30
|
|
|
const struct node_id *nodeid)
|
2019-09-02 22:28:05 +08:00
|
|
|
{
|
2023-06-27 19:26:27 -07:00
|
|
|
/* Old style: Add raw fields without disconnect key */
|
2024-01-25 10:58:55 +10:30
|
|
|
if (lightningd_deprecated_out_ok(ld, ld->deprecated_ok,
|
|
|
|
"disconnect_notification", "rawfields",
|
|
|
|
"v23.08", "v24.08")) {
|
2023-07-07 11:39:38 +09:30
|
|
|
json_add_disconnect_fields(stream, nodeid);
|
2024-01-25 10:58:55 +10:30
|
|
|
}
|
2023-06-27 19:26:27 -07:00
|
|
|
json_object_start(stream, "disconnect");
|
|
|
|
json_add_disconnect_fields(stream, nodeid);
|
|
|
|
json_object_end(stream);
|
2019-09-02 22:28:05 +08:00
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(disconnect);
|
2019-09-02 22:28:05 +08:00
|
|
|
|
2019-04-08 19:28:32 +09:30
|
|
|
void notify_disconnect(struct lightningd *ld, struct node_id *nodeid)
|
2018-12-13 13:58:40 +01:00
|
|
|
{
|
2019-09-02 22:28:05 +08:00
|
|
|
struct jsonrpc_notification *n
|
2024-01-25 08:19:20 +10:30
|
|
|
= jsonrpc_notification_start(NULL, "disconnect");
|
|
|
|
disconnect_notification_serialize(n->stream, ld, nodeid);
|
2018-12-13 13:58:40 +01:00
|
|
|
jsonrpc_notification_end(n);
|
|
|
|
plugins_notify(ld->plugins, take(n));
|
|
|
|
}
|
plugin: Add new notification type: warning
This notification bases on `LOG_BROKEN` and `LOG_UNUSUAL` level log.
--Introduction
A notification for topic `warning` is sent every time a new `BROKEN`/
`UNUSUAL` level(in plugins, we use `error`/`warn`) log generated, which
means an unusual/borken thing happens, such as channel failed,
message resolving failed...
```json
{
"warning": {
"level": "warn",
"time": "1559743608.565342521",
"source": "lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:",
"log": "Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg"
}
}
```
1. `level` is `warn` or `error`:
`warn` means something seems bad happened and it's under control, but
we'd better check it;
`error` means something extremely bad is out of control, and it may lead
to crash;
2. `time` is the second since epoch;
3. `source`, in fact, is the `prefix` of the log_entry. It means where
the event happened, it may have the following forms:
`<node_id> chan #<db_id_of_channel>:`, `lightningd(<lightningd_pid>):`,
`plugin-<plugin_name>:`, `<daemon_name>(<daemon_pid>):`, `jsonrpc:`,
`jcon fd <error_fd_to_jsonrpc>:`, `plugin-manager`;
4. `log` is the context of the original log entry.
--Note:
1. The main code uses `UNUSUAL`/`BROKEN`, and plugin module uses `warn`
/`error`, considering the consistency with plugin, warning choose `warn`
/`error`. But users who use c-lightning with plugins may want to
`getlog` with specified level when receive warning. It's the duty for
plugin dev to turn `warn`/`error` into `UNUSUAL`/`BROKEN` and present it
to the users, or pass it directly to `getlog`;
2. About time, `json_log()` in `log` module uses the Relative Time, from
the time when `log_book` inited to the time when this event happend.
But I consider the `UNUSUAL`/`BROKEN` event is rare, and it is very
likely to happen after running for a long time, so for users, they will
pay more attention to Absolute Time.
-- Related Change
1. Remove the definitions of `log`, `log_book`, `log_entry` from `log.c`
to `log.h`, then they can be used in warning declaration and definition.
2. Remove `void json_add_time(struct json_stream *result, const char
*fieldname, struct timespec ts)` from `log.c` to `json.c`, and add
related declaration in `json.h`. Now the notification function in
`notification.c` can call it.
2. Add a pointer to `struct lightningd` in `struct log_book`. This may
affect the independence of the `log` module, but storing a pointer to
`ld` is more direct;
2019-06-04 02:26:58 +08:00
|
|
|
|
|
|
|
/*'warning' is based on LOG_UNUSUAL/LOG_BROKEN level log
|
|
|
|
*(in plugin module, they're 'warn'/'error' level). */
|
2019-09-02 22:28:46 +08:00
|
|
|
static void warning_notification_serialize(struct json_stream *stream,
|
|
|
|
struct log_entry *l)
|
plugin: Add new notification type: warning
This notification bases on `LOG_BROKEN` and `LOG_UNUSUAL` level log.
--Introduction
A notification for topic `warning` is sent every time a new `BROKEN`/
`UNUSUAL` level(in plugins, we use `error`/`warn`) log generated, which
means an unusual/borken thing happens, such as channel failed,
message resolving failed...
```json
{
"warning": {
"level": "warn",
"time": "1559743608.565342521",
"source": "lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:",
"log": "Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg"
}
}
```
1. `level` is `warn` or `error`:
`warn` means something seems bad happened and it's under control, but
we'd better check it;
`error` means something extremely bad is out of control, and it may lead
to crash;
2. `time` is the second since epoch;
3. `source`, in fact, is the `prefix` of the log_entry. It means where
the event happened, it may have the following forms:
`<node_id> chan #<db_id_of_channel>:`, `lightningd(<lightningd_pid>):`,
`plugin-<plugin_name>:`, `<daemon_name>(<daemon_pid>):`, `jsonrpc:`,
`jcon fd <error_fd_to_jsonrpc>:`, `plugin-manager`;
4. `log` is the context of the original log entry.
--Note:
1. The main code uses `UNUSUAL`/`BROKEN`, and plugin module uses `warn`
/`error`, considering the consistency with plugin, warning choose `warn`
/`error`. But users who use c-lightning with plugins may want to
`getlog` with specified level when receive warning. It's the duty for
plugin dev to turn `warn`/`error` into `UNUSUAL`/`BROKEN` and present it
to the users, or pass it directly to `getlog`;
2. About time, `json_log()` in `log` module uses the Relative Time, from
the time when `log_book` inited to the time when this event happend.
But I consider the `UNUSUAL`/`BROKEN` event is rare, and it is very
likely to happen after running for a long time, so for users, they will
pay more attention to Absolute Time.
-- Related Change
1. Remove the definitions of `log`, `log_book`, `log_entry` from `log.c`
to `log.h`, then they can be used in warning declaration and definition.
2. Remove `void json_add_time(struct json_stream *result, const char
*fieldname, struct timespec ts)` from `log.c` to `json.c`, and add
related declaration in `json.h`. Now the notification function in
`notification.c` can call it.
2. Add a pointer to `struct lightningd` in `struct log_book`. This may
affect the independence of the `log` module, but storing a pointer to
`ld` is more direct;
2019-06-04 02:26:58 +08:00
|
|
|
{
|
|
|
|
/* Choose "BROKEN"/"UNUSUAL" to keep consistent with the habit
|
|
|
|
* of plugin. But this may confuses the users who want to 'getlog'
|
|
|
|
* with the level indicated by notifications. It is the duty of a
|
2024-01-11 16:05:46 +01:00
|
|
|
* plugin to eliminate this misunderstanding. */
|
2019-09-02 22:28:46 +08:00
|
|
|
json_add_string(stream, "level",
|
plugin: Add new notification type: warning
This notification bases on `LOG_BROKEN` and `LOG_UNUSUAL` level log.
--Introduction
A notification for topic `warning` is sent every time a new `BROKEN`/
`UNUSUAL` level(in plugins, we use `error`/`warn`) log generated, which
means an unusual/borken thing happens, such as channel failed,
message resolving failed...
```json
{
"warning": {
"level": "warn",
"time": "1559743608.565342521",
"source": "lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:",
"log": "Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg"
}
}
```
1. `level` is `warn` or `error`:
`warn` means something seems bad happened and it's under control, but
we'd better check it;
`error` means something extremely bad is out of control, and it may lead
to crash;
2. `time` is the second since epoch;
3. `source`, in fact, is the `prefix` of the log_entry. It means where
the event happened, it may have the following forms:
`<node_id> chan #<db_id_of_channel>:`, `lightningd(<lightningd_pid>):`,
`plugin-<plugin_name>:`, `<daemon_name>(<daemon_pid>):`, `jsonrpc:`,
`jcon fd <error_fd_to_jsonrpc>:`, `plugin-manager`;
4. `log` is the context of the original log entry.
--Note:
1. The main code uses `UNUSUAL`/`BROKEN`, and plugin module uses `warn`
/`error`, considering the consistency with plugin, warning choose `warn`
/`error`. But users who use c-lightning with plugins may want to
`getlog` with specified level when receive warning. It's the duty for
plugin dev to turn `warn`/`error` into `UNUSUAL`/`BROKEN` and present it
to the users, or pass it directly to `getlog`;
2. About time, `json_log()` in `log` module uses the Relative Time, from
the time when `log_book` inited to the time when this event happend.
But I consider the `UNUSUAL`/`BROKEN` event is rare, and it is very
likely to happen after running for a long time, so for users, they will
pay more attention to Absolute Time.
-- Related Change
1. Remove the definitions of `log`, `log_book`, `log_entry` from `log.c`
to `log.h`, then they can be used in warning declaration and definition.
2. Remove `void json_add_time(struct json_stream *result, const char
*fieldname, struct timespec ts)` from `log.c` to `json.c`, and add
related declaration in `json.h`. Now the notification function in
`notification.c` can call it.
2. Add a pointer to `struct lightningd` in `struct log_book`. This may
affect the independence of the `log` module, but storing a pointer to
`ld` is more direct;
2019-06-04 02:26:58 +08:00
|
|
|
l->level == LOG_BROKEN ? "error"
|
|
|
|
: "warn");
|
|
|
|
/* unsuaul/broken event is rare, plugin pay more attentions on
|
|
|
|
* the absolute time, like when channels failed. */
|
2023-09-14 12:10:43 +09:30
|
|
|
json_add_timestr(stream, "time", l->time.ts);
|
2023-10-02 09:29:50 +10:30
|
|
|
json_add_timeiso(stream, "timestamp", l->time);
|
2021-11-25 06:29:18 +10:30
|
|
|
json_add_string(stream, "source", l->prefix->prefix);
|
2019-09-02 22:28:46 +08:00
|
|
|
json_add_string(stream, "log", l->log);
|
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(warning);
|
2019-09-02 22:28:46 +08:00
|
|
|
|
|
|
|
void notify_warning(struct lightningd *ld, struct log_entry *l)
|
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("warning");
|
|
|
|
warning_notification_serialize(n->stream, l);
|
|
|
|
notify_send(ld, n);
|
2019-07-21 13:39:15 +02:00
|
|
|
}
|
|
|
|
|
2023-11-21 12:09:18 +01:00
|
|
|
static void custommsg_notification_serialize(struct json_stream *stream,
|
2024-01-25 08:19:20 +10:30
|
|
|
const struct node_id *peer_id,
|
2023-11-21 12:09:18 +01:00
|
|
|
const u8 *msg)
|
|
|
|
{
|
|
|
|
json_add_node_id(stream, "peer_id", peer_id);
|
2024-01-25 08:19:20 +10:30
|
|
|
json_add_hex_talarr(stream, "payload", msg);
|
2023-11-21 12:09:18 +01:00
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(custommsg);
|
2023-11-21 12:09:18 +01:00
|
|
|
|
|
|
|
void notify_custommsg(struct lightningd *ld,
|
|
|
|
const struct node_id *peer_id,
|
|
|
|
const u8 *msg)
|
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("custommsg");
|
|
|
|
custommsg_notification_serialize(n->stream, peer_id, msg);
|
|
|
|
notify_send(ld, n);
|
2023-11-21 12:09:18 +01:00
|
|
|
}
|
|
|
|
|
2019-09-02 22:30:32 +08:00
|
|
|
static void invoice_payment_notification_serialize(struct json_stream *stream,
|
|
|
|
struct amount_msat amount,
|
2024-01-25 08:19:20 +10:30
|
|
|
const struct preimage *preimage,
|
2023-10-26 14:02:13 +10:30
|
|
|
const struct json_escape *label,
|
|
|
|
const struct bitcoin_outpoint *outpoint)
|
2019-09-02 22:30:32 +08:00
|
|
|
{
|
2023-11-21 11:09:07 +10:30
|
|
|
json_add_amount_msat(stream, "msat", amount);
|
2024-01-25 08:19:20 +10:30
|
|
|
json_add_preimage(stream, "preimage", preimage);
|
2023-10-26 14:02:13 +10:30
|
|
|
if (outpoint)
|
|
|
|
json_add_outpoint(stream, "outpoint", outpoint);
|
2019-09-02 22:30:32 +08:00
|
|
|
json_add_escaped_string(stream, "label", label);
|
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(invoice_payment)
|
2019-09-02 22:30:32 +08:00
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
void notify_invoice_payment(struct lightningd *ld,
|
|
|
|
struct amount_msat amount,
|
|
|
|
const struct preimage *preimage,
|
|
|
|
const struct json_escape *label,
|
2023-10-26 14:02:13 +10:30
|
|
|
const struct bitcoin_outpoint *outpoint)
|
2019-07-21 13:39:15 +02:00
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("invoice_payment");
|
|
|
|
invoice_payment_notification_serialize(n->stream, amount, preimage, label, outpoint);
|
|
|
|
notify_send(ld, n);
|
2019-07-21 13:39:15 +02:00
|
|
|
}
|
2019-07-25 16:11:44 +02:00
|
|
|
|
2020-04-21 11:04:01 +10:00
|
|
|
static void invoice_creation_notification_serialize(struct json_stream *stream,
|
2024-01-25 08:19:20 +10:30
|
|
|
const struct amount_msat *amount,
|
|
|
|
const struct preimage *preimage,
|
|
|
|
const struct json_escape *label)
|
2020-04-21 11:04:01 +10:00
|
|
|
{
|
|
|
|
if (amount != NULL)
|
2023-11-21 11:09:07 +10:30
|
|
|
json_add_amount_msat(stream, "msat", *amount);
|
2020-04-21 11:04:01 +10:00
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
json_add_preimage(stream, "preimage", preimage);
|
2020-04-21 11:04:01 +10:00
|
|
|
json_add_escaped_string(stream, "label", label);
|
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(invoice_creation)
|
2020-04-21 11:04:01 +10:00
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
void notify_invoice_creation(struct lightningd *ld,
|
|
|
|
const struct amount_msat *amount,
|
|
|
|
const struct preimage *preimage,
|
2020-04-21 11:04:01 +10:00
|
|
|
const struct json_escape *label)
|
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("invoice_creation");
|
|
|
|
invoice_creation_notification_serialize(n->stream, amount, preimage, label);
|
|
|
|
notify_send(ld, n);
|
2020-04-21 11:04:01 +10:00
|
|
|
}
|
|
|
|
|
2021-10-13 14:15:36 +10:30
|
|
|
/* FIXME: Use outpoint here! */
|
2019-09-02 22:31:15 +08:00
|
|
|
static void channel_opened_notification_serialize(struct json_stream *stream,
|
2023-07-06 17:06:50 +09:30
|
|
|
struct lightningd *ld,
|
2024-01-25 08:19:20 +10:30
|
|
|
const struct node_id *node_id,
|
|
|
|
const struct amount_sat *funding_sat,
|
|
|
|
const struct bitcoin_txid *funding_txid,
|
2022-09-10 11:41:31 +09:30
|
|
|
bool channel_ready)
|
2019-09-02 22:31:15 +08:00
|
|
|
{
|
|
|
|
json_add_node_id(stream, "id", node_id);
|
2023-03-14 15:49:50 +10:30
|
|
|
json_add_amount_sat_msat(stream, "funding_msat", *funding_sat);
|
2019-09-02 22:31:15 +08:00
|
|
|
json_add_txid(stream, "funding_txid", funding_txid);
|
2022-09-10 11:41:31 +09:30
|
|
|
json_add_bool(stream, "channel_ready", channel_ready);
|
2019-09-02 22:31:15 +08:00
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(channel_opened)
|
2019-09-02 22:31:15 +08:00
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
void notify_channel_opened(struct lightningd *ld,
|
|
|
|
const struct node_id *node_id,
|
|
|
|
const struct amount_sat *funding_sat,
|
|
|
|
const struct bitcoin_txid *funding_txid,
|
2022-09-10 11:41:31 +09:30
|
|
|
bool channel_ready)
|
2019-07-25 16:11:44 +02:00
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("channel_opened");
|
|
|
|
channel_opened_notification_serialize(n->stream, ld, node_id, funding_sat, funding_txid, channel_ready);
|
|
|
|
notify_send(ld, n);
|
2019-07-25 16:11:44 +02:00
|
|
|
}
|
Plugin: New notification type, forward_event
`forward_event`
A notification for topic `forward_event` is sent every time the status
of a forward payment is set. The json format is same as the API
`listforwards`.
```json
{
"forward_event": {
"payment_hash": "f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2",
"in_channel": "103x2x1",
"out_channel": "103x1x1",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "settled",
"received_time": 1560696342.368,
"resolved_time": 1560696342.556
}
}
```
or
```json
{
"forward_event": {
"payment_hash": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"in_channel": "103x2x1",
"out_channel": "110x1x0",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "local_failed",
"failcode": 16392,
"failreason": "WIRE_PERMANENT_CHANNEL_FAILURE",
"received_time": 1560696343.052
}
}
```
- The status includes `offered`, `settled`, `failed` and `local_failed`,
and they are all string type in json.
- When the forward payment is valid for us, we'll set `offered`
and send the forward payment to next hop to resolve;
- When the payment forwarded by us gets paid eventually, the forward
payment will change the status from `offered` to `settled`;
- If payment fails locally(like failing to resolve locally) or the
corresponding htlc with next hop fails(like htlc timeout), we will
set the status as `local_failed`. `local_failed` may be set before
setting `offered` or after setting `offered`. In fact, from the
time we receive the htlc of the previous hop, all we can know the
cause of the failure is treated as `local_failed`. `local_failed`
only occuors locally or happens in the htlc between us and next hop;
- If `local_failed` is set before `offered`, this
means we just received htlc from the previous hop and haven't
generate htlc for next hop. In this case, the json of `forward_event`
sets the fields of `out_msatoshi`, `out_msat`,`fee` and `out_channel`
as 0;
- Note: In fact, for this case we may be not sure if this incoming
htlc represents a pay to us or a payment we need to forward.
We just simply treat all incoming failed to resolve as
`local_failed`.
- Only in `local_failed` case, json includes `failcode` and
`failreason` fields;
- `failed` means the payment forwarded by us fails in the
latter hops, and the failure isn't related to us, so we aren't
accessed to the fail reason. `failed` must be set after
`offered`.
- `failed` case doesn't include `failcode` and `failreason`
fields;
- `received_time` means when we received the htlc of this payment from
the previous peer. It will be contained into all status case;
- `resolved_time` means when the htlc of this payment between us and the
next peer was resolved. The resolved result may success or fail, so
only `settled` and `failed` case contain `resolved_time`;
- The `failcode` and `failreason` are defined in [BOLT 4][bolt4-failure-codes].
2019-06-15 21:09:09 +08:00
|
|
|
|
2020-09-08 16:11:05 +02:00
|
|
|
static void channel_state_changed_notification_serialize(struct json_stream *stream,
|
2023-10-02 09:29:50 +10:30
|
|
|
const struct node_id *peer_id,
|
|
|
|
const struct channel_id *cid,
|
|
|
|
const struct short_channel_id *scid,
|
|
|
|
struct timeabs timestamp,
|
2020-09-08 16:11:05 +02:00
|
|
|
enum channel_state old_state,
|
feat: adds state change cause and message
This adds a `state_change` 'cause' to a channel.
A 'cause' is some initial 'reason' a channel was created or closed by:
/* Anything other than the reasons below. Should not happen. */
REASON_UNKNOWN,
/* Unconscious internal reasons, e.g. dev fail of a channel. */
REASON_LOCAL,
/* The operator or a plugin opened or closed a channel by intention. */
REASON_USER,
/* The remote closed or funded a channel with us by intention. */
REASON_REMOTE,
/* E.g. We need to close a channel because of bad signatures and such. */
REASON_PROTOCOL,
/* A channel was closed onchain, while we were offline. */
/* Note: This is very likely a conscious remote decision. */
REASON_ONCHAIN
If a 'cause' is known and a subsequent state change is made with
`REASON_UNKNOWN` the preceding cause will be used as reason, since a lot
(all `REASON_UNKNOWN`) state changes are a subsequent consequences of a prior
cause: local, user, remote, protocol or onchain.
Changelog-Added: Plugins: Channel closure resaon/cause to channel_state_changed notification
2020-10-28 11:46:12 +01:00
|
|
|
enum channel_state new_state,
|
|
|
|
enum state_change cause,
|
2023-10-02 09:29:50 +10:30
|
|
|
const char *message)
|
2020-09-08 16:11:05 +02:00
|
|
|
{
|
|
|
|
json_add_node_id(stream, "peer_id", peer_id);
|
2020-10-08 15:41:12 -05:00
|
|
|
json_add_channel_id(stream, "channel_id", cid);
|
2020-09-08 16:11:05 +02:00
|
|
|
if (scid)
|
2024-03-20 12:29:51 +10:30
|
|
|
json_add_short_channel_id(stream, "short_channel_id", *scid);
|
2020-09-08 16:11:05 +02:00
|
|
|
else
|
|
|
|
json_add_null(stream, "short_channel_id");
|
2020-10-28 11:46:21 +01:00
|
|
|
json_add_timeiso(stream, "timestamp", timestamp);
|
2020-09-08 16:11:05 +02:00
|
|
|
json_add_string(stream, "old_state", channel_state_str(old_state));
|
|
|
|
json_add_string(stream, "new_state", channel_state_str(new_state));
|
feat: adds state change cause and message
This adds a `state_change` 'cause' to a channel.
A 'cause' is some initial 'reason' a channel was created or closed by:
/* Anything other than the reasons below. Should not happen. */
REASON_UNKNOWN,
/* Unconscious internal reasons, e.g. dev fail of a channel. */
REASON_LOCAL,
/* The operator or a plugin opened or closed a channel by intention. */
REASON_USER,
/* The remote closed or funded a channel with us by intention. */
REASON_REMOTE,
/* E.g. We need to close a channel because of bad signatures and such. */
REASON_PROTOCOL,
/* A channel was closed onchain, while we were offline. */
/* Note: This is very likely a conscious remote decision. */
REASON_ONCHAIN
If a 'cause' is known and a subsequent state change is made with
`REASON_UNKNOWN` the preceding cause will be used as reason, since a lot
(all `REASON_UNKNOWN`) state changes are a subsequent consequences of a prior
cause: local, user, remote, protocol or onchain.
Changelog-Added: Plugins: Channel closure resaon/cause to channel_state_changed notification
2020-10-28 11:46:12 +01:00
|
|
|
json_add_string(stream, "cause", channel_change_state_reason_str(cause));
|
|
|
|
if (message != NULL)
|
|
|
|
json_add_string(stream, "message", message);
|
|
|
|
else
|
|
|
|
json_add_null(stream, "message");
|
2020-09-08 16:11:05 +02:00
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(channel_state_changed)
|
2020-09-08 16:11:05 +02:00
|
|
|
|
|
|
|
void notify_channel_state_changed(struct lightningd *ld,
|
2023-10-02 09:29:50 +10:30
|
|
|
const struct node_id *peer_id,
|
|
|
|
const struct channel_id *cid,
|
|
|
|
const struct short_channel_id *scid,
|
|
|
|
struct timeabs timestamp,
|
2020-09-08 16:11:05 +02:00
|
|
|
enum channel_state old_state,
|
feat: adds state change cause and message
This adds a `state_change` 'cause' to a channel.
A 'cause' is some initial 'reason' a channel was created or closed by:
/* Anything other than the reasons below. Should not happen. */
REASON_UNKNOWN,
/* Unconscious internal reasons, e.g. dev fail of a channel. */
REASON_LOCAL,
/* The operator or a plugin opened or closed a channel by intention. */
REASON_USER,
/* The remote closed or funded a channel with us by intention. */
REASON_REMOTE,
/* E.g. We need to close a channel because of bad signatures and such. */
REASON_PROTOCOL,
/* A channel was closed onchain, while we were offline. */
/* Note: This is very likely a conscious remote decision. */
REASON_ONCHAIN
If a 'cause' is known and a subsequent state change is made with
`REASON_UNKNOWN` the preceding cause will be used as reason, since a lot
(all `REASON_UNKNOWN`) state changes are a subsequent consequences of a prior
cause: local, user, remote, protocol or onchain.
Changelog-Added: Plugins: Channel closure resaon/cause to channel_state_changed notification
2020-10-28 11:46:12 +01:00
|
|
|
enum channel_state new_state,
|
|
|
|
enum state_change cause,
|
2023-10-02 09:29:50 +10:30
|
|
|
const char *message)
|
2020-09-08 16:11:05 +02:00
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("channel_state_changed");
|
|
|
|
channel_state_changed_notification_serialize(n->stream, peer_id, cid, scid, timestamp, old_state, new_state, cause, message);
|
|
|
|
notify_send(ld, n);
|
2020-09-08 16:11:05 +02:00
|
|
|
}
|
|
|
|
|
2019-09-02 22:31:51 +08:00
|
|
|
static void forward_event_notification_serialize(struct json_stream *stream,
|
|
|
|
const struct htlc_in *in,
|
2020-02-13 12:41:01 +10:30
|
|
|
const struct short_channel_id *scid_out,
|
|
|
|
const struct amount_msat *amount_out,
|
2019-09-02 22:31:51 +08:00
|
|
|
enum forward_status state,
|
2020-08-31 10:43:25 +09:30
|
|
|
enum onion_wire failcode,
|
2022-03-31 13:44:27 +10:30
|
|
|
struct timeabs *resolved_time,
|
2023-10-28 13:42:06 +10:30
|
|
|
enum forward_style forward_style,
|
|
|
|
u64 created_index,
|
|
|
|
u64 updated_index)
|
Plugin: New notification type, forward_event
`forward_event`
A notification for topic `forward_event` is sent every time the status
of a forward payment is set. The json format is same as the API
`listforwards`.
```json
{
"forward_event": {
"payment_hash": "f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2",
"in_channel": "103x2x1",
"out_channel": "103x1x1",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "settled",
"received_time": 1560696342.368,
"resolved_time": 1560696342.556
}
}
```
or
```json
{
"forward_event": {
"payment_hash": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"in_channel": "103x2x1",
"out_channel": "110x1x0",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "local_failed",
"failcode": 16392,
"failreason": "WIRE_PERMANENT_CHANNEL_FAILURE",
"received_time": 1560696343.052
}
}
```
- The status includes `offered`, `settled`, `failed` and `local_failed`,
and they are all string type in json.
- When the forward payment is valid for us, we'll set `offered`
and send the forward payment to next hop to resolve;
- When the payment forwarded by us gets paid eventually, the forward
payment will change the status from `offered` to `settled`;
- If payment fails locally(like failing to resolve locally) or the
corresponding htlc with next hop fails(like htlc timeout), we will
set the status as `local_failed`. `local_failed` may be set before
setting `offered` or after setting `offered`. In fact, from the
time we receive the htlc of the previous hop, all we can know the
cause of the failure is treated as `local_failed`. `local_failed`
only occuors locally or happens in the htlc between us and next hop;
- If `local_failed` is set before `offered`, this
means we just received htlc from the previous hop and haven't
generate htlc for next hop. In this case, the json of `forward_event`
sets the fields of `out_msatoshi`, `out_msat`,`fee` and `out_channel`
as 0;
- Note: In fact, for this case we may be not sure if this incoming
htlc represents a pay to us or a payment we need to forward.
We just simply treat all incoming failed to resolve as
`local_failed`.
- Only in `local_failed` case, json includes `failcode` and
`failreason` fields;
- `failed` means the payment forwarded by us fails in the
latter hops, and the failure isn't related to us, so we aren't
accessed to the fail reason. `failed` must be set after
`offered`.
- `failed` case doesn't include `failcode` and `failreason`
fields;
- `received_time` means when we received the htlc of this payment from
the previous peer. It will be contained into all status case;
- `resolved_time` means when the htlc of this payment between us and the
next peer was resolved. The resolved result may success or fail, so
only `settled` and `failed` case contain `resolved_time`;
- The `failcode` and `failreason` are defined in [BOLT 4][bolt4-failure-codes].
2019-06-15 21:09:09 +08:00
|
|
|
{
|
|
|
|
/* Here is more neat to initial a forwarding structure than
|
|
|
|
* to pass in a bunch of parameters directly*/
|
|
|
|
struct forwarding *cur = tal(tmpctx, struct forwarding);
|
2022-05-06 15:40:23 +02:00
|
|
|
|
|
|
|
/* We use the LOCAL alias, not the REMOTE, despite the route
|
|
|
|
* the the sender is using probably using the REMOTE
|
|
|
|
* alias. The LOCAL one is controlled by us, and we keep it
|
|
|
|
* stable. */
|
2024-03-20 12:29:51 +10:30
|
|
|
cur->channel_in = channel_scid_or_local_alias(in->key.channel);
|
2022-05-06 15:40:23 +02:00
|
|
|
|
Plugin: New notification type, forward_event
`forward_event`
A notification for topic `forward_event` is sent every time the status
of a forward payment is set. The json format is same as the API
`listforwards`.
```json
{
"forward_event": {
"payment_hash": "f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2",
"in_channel": "103x2x1",
"out_channel": "103x1x1",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "settled",
"received_time": 1560696342.368,
"resolved_time": 1560696342.556
}
}
```
or
```json
{
"forward_event": {
"payment_hash": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"in_channel": "103x2x1",
"out_channel": "110x1x0",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "local_failed",
"failcode": 16392,
"failreason": "WIRE_PERMANENT_CHANNEL_FAILURE",
"received_time": 1560696343.052
}
}
```
- The status includes `offered`, `settled`, `failed` and `local_failed`,
and they are all string type in json.
- When the forward payment is valid for us, we'll set `offered`
and send the forward payment to next hop to resolve;
- When the payment forwarded by us gets paid eventually, the forward
payment will change the status from `offered` to `settled`;
- If payment fails locally(like failing to resolve locally) or the
corresponding htlc with next hop fails(like htlc timeout), we will
set the status as `local_failed`. `local_failed` may be set before
setting `offered` or after setting `offered`. In fact, from the
time we receive the htlc of the previous hop, all we can know the
cause of the failure is treated as `local_failed`. `local_failed`
only occuors locally or happens in the htlc between us and next hop;
- If `local_failed` is set before `offered`, this
means we just received htlc from the previous hop and haven't
generate htlc for next hop. In this case, the json of `forward_event`
sets the fields of `out_msatoshi`, `out_msat`,`fee` and `out_channel`
as 0;
- Note: In fact, for this case we may be not sure if this incoming
htlc represents a pay to us or a payment we need to forward.
We just simply treat all incoming failed to resolve as
`local_failed`.
- Only in `local_failed` case, json includes `failcode` and
`failreason` fields;
- `failed` means the payment forwarded by us fails in the
latter hops, and the failure isn't related to us, so we aren't
accessed to the fail reason. `failed` must be set after
`offered`.
- `failed` case doesn't include `failcode` and `failreason`
fields;
- `received_time` means when we received the htlc of this payment from
the previous peer. It will be contained into all status case;
- `resolved_time` means when the htlc of this payment between us and the
next peer was resolved. The resolved result may success or fail, so
only `settled` and `failed` case contain `resolved_time`;
- The `failcode` and `failreason` are defined in [BOLT 4][bolt4-failure-codes].
2019-06-15 21:09:09 +08:00
|
|
|
cur->msat_in = in->msat;
|
2020-02-13 12:41:01 +10:30
|
|
|
if (scid_out) {
|
|
|
|
cur->channel_out = *scid_out;
|
|
|
|
if (amount_out) {
|
|
|
|
cur->msat_out = *amount_out;
|
2020-02-13 16:01:04 +10:30
|
|
|
if (!amount_msat_sub(&cur->fee,
|
|
|
|
in->msat, *amount_out))
|
|
|
|
abort();
|
2020-02-13 12:41:01 +10:30
|
|
|
} else {
|
|
|
|
cur->msat_out = AMOUNT_MSAT(0);
|
|
|
|
cur->fee = AMOUNT_MSAT(0);
|
|
|
|
}
|
Plugin: New notification type, forward_event
`forward_event`
A notification for topic `forward_event` is sent every time the status
of a forward payment is set. The json format is same as the API
`listforwards`.
```json
{
"forward_event": {
"payment_hash": "f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2",
"in_channel": "103x2x1",
"out_channel": "103x1x1",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "settled",
"received_time": 1560696342.368,
"resolved_time": 1560696342.556
}
}
```
or
```json
{
"forward_event": {
"payment_hash": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"in_channel": "103x2x1",
"out_channel": "110x1x0",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "local_failed",
"failcode": 16392,
"failreason": "WIRE_PERMANENT_CHANNEL_FAILURE",
"received_time": 1560696343.052
}
}
```
- The status includes `offered`, `settled`, `failed` and `local_failed`,
and they are all string type in json.
- When the forward payment is valid for us, we'll set `offered`
and send the forward payment to next hop to resolve;
- When the payment forwarded by us gets paid eventually, the forward
payment will change the status from `offered` to `settled`;
- If payment fails locally(like failing to resolve locally) or the
corresponding htlc with next hop fails(like htlc timeout), we will
set the status as `local_failed`. `local_failed` may be set before
setting `offered` or after setting `offered`. In fact, from the
time we receive the htlc of the previous hop, all we can know the
cause of the failure is treated as `local_failed`. `local_failed`
only occuors locally or happens in the htlc between us and next hop;
- If `local_failed` is set before `offered`, this
means we just received htlc from the previous hop and haven't
generate htlc for next hop. In this case, the json of `forward_event`
sets the fields of `out_msatoshi`, `out_msat`,`fee` and `out_channel`
as 0;
- Note: In fact, for this case we may be not sure if this incoming
htlc represents a pay to us or a payment we need to forward.
We just simply treat all incoming failed to resolve as
`local_failed`.
- Only in `local_failed` case, json includes `failcode` and
`failreason` fields;
- `failed` means the payment forwarded by us fails in the
latter hops, and the failure isn't related to us, so we aren't
accessed to the fail reason. `failed` must be set after
`offered`.
- `failed` case doesn't include `failcode` and `failreason`
fields;
- `received_time` means when we received the htlc of this payment from
the previous peer. It will be contained into all status case;
- `resolved_time` means when the htlc of this payment between us and the
next peer was resolved. The resolved result may success or fail, so
only `settled` and `failed` case contain `resolved_time`;
- The `failcode` and `failreason` are defined in [BOLT 4][bolt4-failure-codes].
2019-06-15 21:09:09 +08:00
|
|
|
} else {
|
|
|
|
cur->channel_out.u64 = 0;
|
|
|
|
cur->msat_out = AMOUNT_MSAT(0);
|
|
|
|
cur->fee = AMOUNT_MSAT(0);
|
|
|
|
}
|
2022-09-19 10:19:53 +09:30
|
|
|
cur->htlc_id_out = NULL;
|
Plugin: New notification type, forward_event
`forward_event`
A notification for topic `forward_event` is sent every time the status
of a forward payment is set. The json format is same as the API
`listforwards`.
```json
{
"forward_event": {
"payment_hash": "f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2",
"in_channel": "103x2x1",
"out_channel": "103x1x1",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "settled",
"received_time": 1560696342.368,
"resolved_time": 1560696342.556
}
}
```
or
```json
{
"forward_event": {
"payment_hash": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"in_channel": "103x2x1",
"out_channel": "110x1x0",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "local_failed",
"failcode": 16392,
"failreason": "WIRE_PERMANENT_CHANNEL_FAILURE",
"received_time": 1560696343.052
}
}
```
- The status includes `offered`, `settled`, `failed` and `local_failed`,
and they are all string type in json.
- When the forward payment is valid for us, we'll set `offered`
and send the forward payment to next hop to resolve;
- When the payment forwarded by us gets paid eventually, the forward
payment will change the status from `offered` to `settled`;
- If payment fails locally(like failing to resolve locally) or the
corresponding htlc with next hop fails(like htlc timeout), we will
set the status as `local_failed`. `local_failed` may be set before
setting `offered` or after setting `offered`. In fact, from the
time we receive the htlc of the previous hop, all we can know the
cause of the failure is treated as `local_failed`. `local_failed`
only occuors locally or happens in the htlc between us and next hop;
- If `local_failed` is set before `offered`, this
means we just received htlc from the previous hop and haven't
generate htlc for next hop. In this case, the json of `forward_event`
sets the fields of `out_msatoshi`, `out_msat`,`fee` and `out_channel`
as 0;
- Note: In fact, for this case we may be not sure if this incoming
htlc represents a pay to us or a payment we need to forward.
We just simply treat all incoming failed to resolve as
`local_failed`.
- Only in `local_failed` case, json includes `failcode` and
`failreason` fields;
- `failed` means the payment forwarded by us fails in the
latter hops, and the failure isn't related to us, so we aren't
accessed to the fail reason. `failed` must be set after
`offered`.
- `failed` case doesn't include `failcode` and `failreason`
fields;
- `received_time` means when we received the htlc of this payment from
the previous peer. It will be contained into all status case;
- `resolved_time` means when the htlc of this payment between us and the
next peer was resolved. The resolved result may success or fail, so
only `settled` and `failed` case contain `resolved_time`;
- The `failcode` and `failreason` are defined in [BOLT 4][bolt4-failure-codes].
2019-06-15 21:09:09 +08:00
|
|
|
cur->status = state;
|
|
|
|
cur->failcode = failcode;
|
|
|
|
cur->received_time = in->received_time;
|
|
|
|
cur->resolved_time = tal_steal(cur, resolved_time);
|
2022-03-31 13:44:27 +10:30
|
|
|
cur->forward_style = forward_style;
|
2022-09-19 10:19:53 +09:30
|
|
|
cur->htlc_id_in = in->key.id;
|
2023-10-28 13:42:06 +10:30
|
|
|
cur->created_index = created_index;
|
|
|
|
cur->updated_index = updated_index;
|
Plugin: New notification type, forward_event
`forward_event`
A notification for topic `forward_event` is sent every time the status
of a forward payment is set. The json format is same as the API
`listforwards`.
```json
{
"forward_event": {
"payment_hash": "f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2",
"in_channel": "103x2x1",
"out_channel": "103x1x1",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "settled",
"received_time": 1560696342.368,
"resolved_time": 1560696342.556
}
}
```
or
```json
{
"forward_event": {
"payment_hash": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"in_channel": "103x2x1",
"out_channel": "110x1x0",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "local_failed",
"failcode": 16392,
"failreason": "WIRE_PERMANENT_CHANNEL_FAILURE",
"received_time": 1560696343.052
}
}
```
- The status includes `offered`, `settled`, `failed` and `local_failed`,
and they are all string type in json.
- When the forward payment is valid for us, we'll set `offered`
and send the forward payment to next hop to resolve;
- When the payment forwarded by us gets paid eventually, the forward
payment will change the status from `offered` to `settled`;
- If payment fails locally(like failing to resolve locally) or the
corresponding htlc with next hop fails(like htlc timeout), we will
set the status as `local_failed`. `local_failed` may be set before
setting `offered` or after setting `offered`. In fact, from the
time we receive the htlc of the previous hop, all we can know the
cause of the failure is treated as `local_failed`. `local_failed`
only occuors locally or happens in the htlc between us and next hop;
- If `local_failed` is set before `offered`, this
means we just received htlc from the previous hop and haven't
generate htlc for next hop. In this case, the json of `forward_event`
sets the fields of `out_msatoshi`, `out_msat`,`fee` and `out_channel`
as 0;
- Note: In fact, for this case we may be not sure if this incoming
htlc represents a pay to us or a payment we need to forward.
We just simply treat all incoming failed to resolve as
`local_failed`.
- Only in `local_failed` case, json includes `failcode` and
`failreason` fields;
- `failed` means the payment forwarded by us fails in the
latter hops, and the failure isn't related to us, so we aren't
accessed to the fail reason. `failed` must be set after
`offered`.
- `failed` case doesn't include `failcode` and `failreason`
fields;
- `received_time` means when we received the htlc of this payment from
the previous peer. It will be contained into all status case;
- `resolved_time` means when the htlc of this payment between us and the
next peer was resolved. The resolved result may success or fail, so
only `settled` and `failed` case contain `resolved_time`;
- The `failcode` and `failreason` are defined in [BOLT 4][bolt4-failure-codes].
2019-06-15 21:09:09 +08:00
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
json_add_forwarding_fields(stream, cur, &in->payment_hash);
|
2019-09-02 22:31:51 +08:00
|
|
|
}
|
Plugin: New notification type, forward_event
`forward_event`
A notification for topic `forward_event` is sent every time the status
of a forward payment is set. The json format is same as the API
`listforwards`.
```json
{
"forward_event": {
"payment_hash": "f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2",
"in_channel": "103x2x1",
"out_channel": "103x1x1",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "settled",
"received_time": 1560696342.368,
"resolved_time": 1560696342.556
}
}
```
or
```json
{
"forward_event": {
"payment_hash": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"in_channel": "103x2x1",
"out_channel": "110x1x0",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "local_failed",
"failcode": 16392,
"failreason": "WIRE_PERMANENT_CHANNEL_FAILURE",
"received_time": 1560696343.052
}
}
```
- The status includes `offered`, `settled`, `failed` and `local_failed`,
and they are all string type in json.
- When the forward payment is valid for us, we'll set `offered`
and send the forward payment to next hop to resolve;
- When the payment forwarded by us gets paid eventually, the forward
payment will change the status from `offered` to `settled`;
- If payment fails locally(like failing to resolve locally) or the
corresponding htlc with next hop fails(like htlc timeout), we will
set the status as `local_failed`. `local_failed` may be set before
setting `offered` or after setting `offered`. In fact, from the
time we receive the htlc of the previous hop, all we can know the
cause of the failure is treated as `local_failed`. `local_failed`
only occuors locally or happens in the htlc between us and next hop;
- If `local_failed` is set before `offered`, this
means we just received htlc from the previous hop and haven't
generate htlc for next hop. In this case, the json of `forward_event`
sets the fields of `out_msatoshi`, `out_msat`,`fee` and `out_channel`
as 0;
- Note: In fact, for this case we may be not sure if this incoming
htlc represents a pay to us or a payment we need to forward.
We just simply treat all incoming failed to resolve as
`local_failed`.
- Only in `local_failed` case, json includes `failcode` and
`failreason` fields;
- `failed` means the payment forwarded by us fails in the
latter hops, and the failure isn't related to us, so we aren't
accessed to the fail reason. `failed` must be set after
`offered`.
- `failed` case doesn't include `failcode` and `failreason`
fields;
- `received_time` means when we received the htlc of this payment from
the previous peer. It will be contained into all status case;
- `resolved_time` means when the htlc of this payment between us and the
next peer was resolved. The resolved result may success or fail, so
only `settled` and `failed` case contain `resolved_time`;
- The `failcode` and `failreason` are defined in [BOLT 4][bolt4-failure-codes].
2019-06-15 21:09:09 +08:00
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(forward_event);
|
2019-09-02 22:31:51 +08:00
|
|
|
|
|
|
|
void notify_forward_event(struct lightningd *ld,
|
|
|
|
const struct htlc_in *in,
|
2020-02-13 12:41:01 +10:30
|
|
|
const struct short_channel_id *scid_out,
|
|
|
|
const struct amount_msat *amount_out,
|
2019-09-02 22:31:51 +08:00
|
|
|
enum forward_status state,
|
2020-08-31 10:43:25 +09:30
|
|
|
enum onion_wire failcode,
|
2022-03-31 13:44:27 +10:30
|
|
|
struct timeabs *resolved_time,
|
2023-10-28 13:42:06 +10:30
|
|
|
enum forward_style forward_style,
|
|
|
|
u64 created_index,
|
|
|
|
u64 updated_index)
|
2019-09-02 22:31:51 +08:00
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("forward_event");
|
|
|
|
forward_event_notification_serialize(n->stream, in, scid_out, amount_out, state, failcode, resolved_time, forward_style, created_index, updated_index);
|
|
|
|
notify_send(ld, n);
|
Plugin: New notification type, forward_event
`forward_event`
A notification for topic `forward_event` is sent every time the status
of a forward payment is set. The json format is same as the API
`listforwards`.
```json
{
"forward_event": {
"payment_hash": "f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2",
"in_channel": "103x2x1",
"out_channel": "103x1x1",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "settled",
"received_time": 1560696342.368,
"resolved_time": 1560696342.556
}
}
```
or
```json
{
"forward_event": {
"payment_hash": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
"in_channel": "103x2x1",
"out_channel": "110x1x0",
"in_msatoshi": 100001001,
"in_msat": "100001001msat",
"out_msatoshi": 100000000,
"out_msat": "100000000msat",
"fee": 1001,
"fee_msat": "1001msat",
"status": "local_failed",
"failcode": 16392,
"failreason": "WIRE_PERMANENT_CHANNEL_FAILURE",
"received_time": 1560696343.052
}
}
```
- The status includes `offered`, `settled`, `failed` and `local_failed`,
and they are all string type in json.
- When the forward payment is valid for us, we'll set `offered`
and send the forward payment to next hop to resolve;
- When the payment forwarded by us gets paid eventually, the forward
payment will change the status from `offered` to `settled`;
- If payment fails locally(like failing to resolve locally) or the
corresponding htlc with next hop fails(like htlc timeout), we will
set the status as `local_failed`. `local_failed` may be set before
setting `offered` or after setting `offered`. In fact, from the
time we receive the htlc of the previous hop, all we can know the
cause of the failure is treated as `local_failed`. `local_failed`
only occuors locally or happens in the htlc between us and next hop;
- If `local_failed` is set before `offered`, this
means we just received htlc from the previous hop and haven't
generate htlc for next hop. In this case, the json of `forward_event`
sets the fields of `out_msatoshi`, `out_msat`,`fee` and `out_channel`
as 0;
- Note: In fact, for this case we may be not sure if this incoming
htlc represents a pay to us or a payment we need to forward.
We just simply treat all incoming failed to resolve as
`local_failed`.
- Only in `local_failed` case, json includes `failcode` and
`failreason` fields;
- `failed` means the payment forwarded by us fails in the
latter hops, and the failure isn't related to us, so we aren't
accessed to the fail reason. `failed` must be set after
`offered`.
- `failed` case doesn't include `failcode` and `failreason`
fields;
- `received_time` means when we received the htlc of this payment from
the previous peer. It will be contained into all status case;
- `resolved_time` means when the htlc of this payment between us and the
next peer was resolved. The resolved result may success or fail, so
only `settled` and `failed` case contain `resolved_time`;
- The `failcode` and `failreason` are defined in [BOLT 4][bolt4-failure-codes].
2019-06-15 21:09:09 +08:00
|
|
|
}
|
plugin: A new notification type, 'sendpay_success'
`sendpay_success`
A notification for topic `sendpay_success` is sent every time a sendpay
success(with `complete` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when these cammand succeeds.
```json
{
"sendpay_success": {
"id": 1,
"payment_hash": "5c85bf402b87d4860f4a728e2e58a2418bda92cd7aea0ce494f11670cfbfb206",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561390572,
"status": "complete",
"payment_preimage": "9540d98095fd7f37687ebb7759e733934234d4f934e34433d4998a37de3733ee"
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_success` will always return the result anytime when sendpay
successes if is was subscribed.
2019-06-25 15:27:35 +08:00
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(sendpay_success);
|
plugin: A new notification type, 'sendpay_success'
`sendpay_success`
A notification for topic `sendpay_success` is sent every time a sendpay
success(with `complete` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when these cammand succeeds.
```json
{
"sendpay_success": {
"id": 1,
"payment_hash": "5c85bf402b87d4860f4a728e2e58a2418bda92cd7aea0ce494f11670cfbfb206",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561390572,
"status": "complete",
"payment_preimage": "9540d98095fd7f37687ebb7759e733934234d4f934e34433d4998a37de3733ee"
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_success` will always return the result anytime when sendpay
successes if is was subscribed.
2019-06-25 15:27:35 +08:00
|
|
|
|
|
|
|
void notify_sendpay_success(struct lightningd *ld,
|
|
|
|
const struct wallet_payment *payment)
|
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("sendpay_success");
|
|
|
|
json_add_payment_fields(n->stream, payment);
|
|
|
|
notify_send(ld, n);
|
plugin: A new notification type, 'sendpay_success'
`sendpay_success`
A notification for topic `sendpay_success` is sent every time a sendpay
success(with `complete` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when these cammand succeeds.
```json
{
"sendpay_success": {
"id": 1,
"payment_hash": "5c85bf402b87d4860f4a728e2e58a2418bda92cd7aea0ce494f11670cfbfb206",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561390572,
"status": "complete",
"payment_preimage": "9540d98095fd7f37687ebb7759e733934234d4f934e34433d4998a37de3733ee"
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_success` will always return the result anytime when sendpay
successes if is was subscribed.
2019-06-25 15:27:35 +08:00
|
|
|
}
|
plugin: Another new notification type, 'sendpay_failure'
(The json when sendpay successes is too different when sendpay fails, so
divide the sendpay result into two notifications: `sendpay_success` and
`sendpay_failure`)
`sendpay_failure`
A notification for topic `sendpay_failure` is sent every time a sendpay
success(with `failed` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when this cammand fails.
```json
{
"sendpay_failure": {
"code": 204,
"message": "failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)",
"data": {
"id": 2,
"payment_hash": "9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561395134,
"status": "failed",
"erring_index": 1,
"failcode": 16394,
"failcodename": "WIRE_UNKNOWN_NEXT_PEER",
"erring_node": "022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59",
"erring_channel": "103x2x1",
"erring_direction": 0
}
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_failure` will always return the result anytime when sendpay
fails if is was subscribed.
2019-06-25 15:45:16 +08:00
|
|
|
|
|
|
|
static void sendpay_failure_notification_serialize(struct json_stream *stream,
|
|
|
|
const struct wallet_payment *payment,
|
2022-09-18 09:50:50 +09:30
|
|
|
enum jsonrpc_errcode pay_errcode,
|
2020-01-23 10:08:04 +10:30
|
|
|
const struct onionreply *onionreply,
|
plugin: Another new notification type, 'sendpay_failure'
(The json when sendpay successes is too different when sendpay fails, so
divide the sendpay result into two notifications: `sendpay_success` and
`sendpay_failure`)
`sendpay_failure`
A notification for topic `sendpay_failure` is sent every time a sendpay
success(with `failed` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when this cammand fails.
```json
{
"sendpay_failure": {
"code": 204,
"message": "failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)",
"data": {
"id": 2,
"payment_hash": "9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561395134,
"status": "failed",
"erring_index": 1,
"failcode": 16394,
"failcodename": "WIRE_UNKNOWN_NEXT_PEER",
"erring_node": "022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59",
"erring_channel": "103x2x1",
"erring_direction": 0
}
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_failure` will always return the result anytime when sendpay
fails if is was subscribed.
2019-06-25 15:45:16 +08:00
|
|
|
const struct routing_failure *fail,
|
2024-01-25 08:19:20 +10:30
|
|
|
const char *errmsg)
|
plugin: Another new notification type, 'sendpay_failure'
(The json when sendpay successes is too different when sendpay fails, so
divide the sendpay result into two notifications: `sendpay_success` and
`sendpay_failure`)
`sendpay_failure`
A notification for topic `sendpay_failure` is sent every time a sendpay
success(with `failed` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when this cammand fails.
```json
{
"sendpay_failure": {
"code": 204,
"message": "failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)",
"data": {
"id": 2,
"payment_hash": "9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561395134,
"status": "failed",
"erring_index": 1,
"failcode": 16394,
"failcodename": "WIRE_UNKNOWN_NEXT_PEER",
"erring_node": "022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59",
"erring_channel": "103x2x1",
"erring_direction": 0
}
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_failure` will always return the result anytime when sendpay
fails if is was subscribed.
2019-06-25 15:45:16 +08:00
|
|
|
{
|
|
|
|
/* In line with the format of json error returned
|
|
|
|
* by sendpay_fail(). */
|
2022-09-18 09:50:50 +09:30
|
|
|
json_add_jsonrpc_errcode(stream, "code", pay_errcode);
|
plugin: Another new notification type, 'sendpay_failure'
(The json when sendpay successes is too different when sendpay fails, so
divide the sendpay result into two notifications: `sendpay_success` and
`sendpay_failure`)
`sendpay_failure`
A notification for topic `sendpay_failure` is sent every time a sendpay
success(with `failed` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when this cammand fails.
```json
{
"sendpay_failure": {
"code": 204,
"message": "failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)",
"data": {
"id": 2,
"payment_hash": "9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561395134,
"status": "failed",
"erring_index": 1,
"failcode": 16394,
"failcodename": "WIRE_UNKNOWN_NEXT_PEER",
"erring_node": "022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59",
"erring_channel": "103x2x1",
"erring_direction": 0
}
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_failure` will always return the result anytime when sendpay
fails if is was subscribed.
2019-06-25 15:45:16 +08:00
|
|
|
json_add_string(stream, "message", errmsg);
|
|
|
|
|
|
|
|
json_object_start(stream, "data");
|
|
|
|
json_sendpay_fail_fields(stream,
|
|
|
|
payment,
|
|
|
|
pay_errcode,
|
|
|
|
onionreply,
|
|
|
|
fail);
|
|
|
|
|
|
|
|
json_object_end(stream); /* .data */
|
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(sendpay_failure);
|
plugin: Another new notification type, 'sendpay_failure'
(The json when sendpay successes is too different when sendpay fails, so
divide the sendpay result into two notifications: `sendpay_success` and
`sendpay_failure`)
`sendpay_failure`
A notification for topic `sendpay_failure` is sent every time a sendpay
success(with `failed` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when this cammand fails.
```json
{
"sendpay_failure": {
"code": 204,
"message": "failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)",
"data": {
"id": 2,
"payment_hash": "9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561395134,
"status": "failed",
"erring_index": 1,
"failcode": 16394,
"failcodename": "WIRE_UNKNOWN_NEXT_PEER",
"erring_node": "022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59",
"erring_channel": "103x2x1",
"erring_direction": 0
}
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_failure` will always return the result anytime when sendpay
fails if is was subscribed.
2019-06-25 15:45:16 +08:00
|
|
|
|
|
|
|
void notify_sendpay_failure(struct lightningd *ld,
|
|
|
|
const struct wallet_payment *payment,
|
2022-09-18 09:50:50 +09:30
|
|
|
enum jsonrpc_errcode pay_errcode,
|
2020-01-23 10:08:04 +10:30
|
|
|
const struct onionreply *onionreply,
|
plugin: Another new notification type, 'sendpay_failure'
(The json when sendpay successes is too different when sendpay fails, so
divide the sendpay result into two notifications: `sendpay_success` and
`sendpay_failure`)
`sendpay_failure`
A notification for topic `sendpay_failure` is sent every time a sendpay
success(with `failed` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when this cammand fails.
```json
{
"sendpay_failure": {
"code": 204,
"message": "failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)",
"data": {
"id": 2,
"payment_hash": "9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561395134,
"status": "failed",
"erring_index": 1,
"failcode": 16394,
"failcodename": "WIRE_UNKNOWN_NEXT_PEER",
"erring_node": "022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59",
"erring_channel": "103x2x1",
"erring_direction": 0
}
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_failure` will always return the result anytime when sendpay
fails if is was subscribed.
2019-06-25 15:45:16 +08:00
|
|
|
const struct routing_failure *fail,
|
2020-01-07 16:31:00 +01:00
|
|
|
const char *errmsg)
|
plugin: Another new notification type, 'sendpay_failure'
(The json when sendpay successes is too different when sendpay fails, so
divide the sendpay result into two notifications: `sendpay_success` and
`sendpay_failure`)
`sendpay_failure`
A notification for topic `sendpay_failure` is sent every time a sendpay
success(with `failed` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when this cammand fails.
```json
{
"sendpay_failure": {
"code": 204,
"message": "failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)",
"data": {
"id": 2,
"payment_hash": "9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561395134,
"status": "failed",
"erring_index": 1,
"failcode": 16394,
"failcodename": "WIRE_UNKNOWN_NEXT_PEER",
"erring_node": "022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59",
"erring_channel": "103x2x1",
"erring_direction": 0
}
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_failure` will always return the result anytime when sendpay
fails if is was subscribed.
2019-06-25 15:45:16 +08:00
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("sendpay_failure");
|
|
|
|
sendpay_failure_notification_serialize(n->stream, payment, pay_errcode, onionreply, fail, errmsg);
|
|
|
|
notify_send(ld, n);
|
plugin: Another new notification type, 'sendpay_failure'
(The json when sendpay successes is too different when sendpay fails, so
divide the sendpay result into two notifications: `sendpay_success` and
`sendpay_failure`)
`sendpay_failure`
A notification for topic `sendpay_failure` is sent every time a sendpay
success(with `failed` status). The json is same as the return value of
command `sendpay`/`waitsendpay` when this cammand fails.
```json
{
"sendpay_failure": {
"code": 204,
"message": "failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)",
"data": {
"id": 2,
"payment_hash": "9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851",
"destination": "035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d",
"msatoshi": 100000000,
"amount_msat": "100000000msat",
"msatoshi_sent": 100001001,
"amount_sent_msat": "100001001msat",
"created_at": 1561395134,
"status": "failed",
"erring_index": 1,
"failcode": 16394,
"failcodename": "WIRE_UNKNOWN_NEXT_PEER",
"erring_node": "022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59",
"erring_channel": "103x2x1",
"erring_direction": 0
}
}
}
```
`sendpay` doesn't wait for the result of sendpay and `waitsendpay`
returns the result of sendpay in specified time or timeout, but
`sendpay_failure` will always return the result anytime when sendpay
fails if is was subscribed.
2019-06-25 15:45:16 +08:00
|
|
|
}
|
2020-03-18 18:35:59 -05:00
|
|
|
|
|
|
|
static void json_mvt_id(struct json_stream *stream, enum mvt_type mvt_type,
|
2024-01-25 08:19:20 +10:30
|
|
|
const struct mvt_id *id)
|
2020-03-18 18:35:59 -05:00
|
|
|
{
|
|
|
|
switch (mvt_type) {
|
|
|
|
case CHAIN_MVT:
|
|
|
|
/* some 'journal entries' don't have a txid */
|
|
|
|
if (id->tx_txid)
|
|
|
|
json_add_string(stream, "txid",
|
2024-03-20 11:17:52 +10:30
|
|
|
fmt_bitcoin_txid(tmpctx,
|
|
|
|
id->tx_txid));
|
2020-03-18 18:35:59 -05:00
|
|
|
/* some chain ledger entries aren't associated with a utxo
|
|
|
|
* e.g. journal updates (due to penalty/state loss) and
|
|
|
|
* chain_fee entries */
|
2021-10-13 14:15:36 +10:30
|
|
|
if (id->outpoint) {
|
2020-03-18 18:35:59 -05:00
|
|
|
json_add_string(stream, "utxo_txid",
|
2024-03-20 11:17:52 +10:30
|
|
|
fmt_bitcoin_txid(tmpctx,
|
|
|
|
&id->outpoint->txid));
|
2021-10-13 14:15:36 +10:30
|
|
|
json_add_u32(stream, "vout", id->outpoint->n);
|
2020-03-18 18:35:59 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
/* on-chain htlcs include a payment hash */
|
|
|
|
if (id->payment_hash)
|
|
|
|
json_add_sha256(stream, "payment_hash", id->payment_hash);
|
|
|
|
return;
|
2024-03-20 11:17:52 +10:30
|
|
|
case CHANNEL_MVT:
|
|
|
|
/* push funding / leases don't have a payment_hash */
|
|
|
|
if (id->payment_hash)
|
|
|
|
json_add_sha256(stream, "payment_hash", id->payment_hash);
|
|
|
|
if (id->part_id)
|
|
|
|
json_add_u64(stream, "part_id", *id->part_id);
|
|
|
|
return;
|
2020-03-18 18:35:59 -05:00
|
|
|
}
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void coin_movement_notification_serialize(struct json_stream *stream,
|
2024-01-25 08:19:20 +10:30
|
|
|
const struct coin_mvt *mvt)
|
2020-03-18 18:35:59 -05:00
|
|
|
{
|
|
|
|
json_add_num(stream, "version", mvt->version);
|
|
|
|
json_add_node_id(stream, "node_id", mvt->node_id);
|
2022-07-19 17:04:38 +09:30
|
|
|
if (mvt->peer_id)
|
|
|
|
json_add_node_id(stream, "peer_id", mvt->peer_id);
|
2020-03-18 18:35:59 -05:00
|
|
|
json_add_string(stream, "type", mvt_type_str(mvt->type));
|
|
|
|
json_add_string(stream, "account_id", mvt->account_id);
|
2022-01-24 12:58:39 -06:00
|
|
|
if (mvt->originating_acct)
|
|
|
|
json_add_string(stream, "originating_account",
|
|
|
|
mvt->originating_acct);
|
2020-03-18 18:35:59 -05:00
|
|
|
json_mvt_id(stream, mvt->type, &mvt->id);
|
2023-03-14 15:51:50 +10:30
|
|
|
json_add_amount_msat(stream, "credit_msat", mvt->credit);
|
|
|
|
json_add_amount_msat(stream, "debit_msat", mvt->debit);
|
2022-06-19 16:49:11 +09:30
|
|
|
|
2021-11-30 14:15:03 -06:00
|
|
|
/* Only chain movements */
|
|
|
|
if (mvt->output_val)
|
2023-03-14 15:49:50 +10:30
|
|
|
json_add_amount_sat_msat(stream,
|
|
|
|
"output_msat", *mvt->output_val);
|
2022-02-16 12:16:39 -06:00
|
|
|
if (mvt->output_count > 0)
|
|
|
|
json_add_num(stream, "output_count",
|
|
|
|
mvt->output_count);
|
|
|
|
|
2022-06-19 16:49:11 +09:30
|
|
|
if (mvt->fees) {
|
2023-03-14 15:51:50 +10:30
|
|
|
json_add_amount_msat(stream, "fees_msat", *mvt->fees);
|
2022-06-19 16:49:11 +09:30
|
|
|
}
|
2021-12-06 12:24:20 -06:00
|
|
|
|
|
|
|
json_array_start(stream, "tags");
|
|
|
|
for (size_t i = 0; i < tal_count(mvt->tags); i++)
|
|
|
|
json_add_string(stream, NULL, mvt_tag_str(mvt->tags[i]));
|
|
|
|
json_array_end(stream);
|
2020-04-03 16:52:35 -05:00
|
|
|
|
2022-02-16 15:36:20 -06:00
|
|
|
if (mvt->type == CHAIN_MVT)
|
|
|
|
json_add_u32(stream, "blockheight", mvt->blockheight);
|
|
|
|
|
2020-03-18 18:35:59 -05:00
|
|
|
json_add_u32(stream, "timestamp", mvt->timestamp);
|
2021-12-29 10:39:58 +10:30
|
|
|
json_add_string(stream, "coin_type", mvt->hrp_name);
|
2020-03-18 18:35:59 -05:00
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(coin_movement);
|
2020-03-18 18:35:59 -05:00
|
|
|
|
|
|
|
void notify_coin_mvt(struct lightningd *ld,
|
|
|
|
const struct coin_mvt *mvt)
|
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("coin_movement");
|
|
|
|
coin_movement_notification_serialize(n->stream, mvt);
|
|
|
|
notify_send(ld, n);
|
2020-03-18 18:35:59 -05:00
|
|
|
}
|
2020-10-08 17:21:20 -05:00
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
static void balance_snapshot_serialize(struct json_stream *stream,
|
|
|
|
const struct balance_snapshot *snap)
|
2021-12-13 16:44:32 -06:00
|
|
|
{
|
|
|
|
json_add_node_id(stream, "node_id", snap->node_id);
|
|
|
|
json_add_u32(stream, "blockheight", snap->blockheight);
|
|
|
|
json_add_u32(stream, "timestamp", snap->timestamp);
|
|
|
|
|
|
|
|
json_array_start(stream, "accounts");
|
|
|
|
for (size_t i = 0; i < tal_count(snap->accts); i++) {
|
|
|
|
json_object_start(stream, NULL);
|
|
|
|
json_add_string(stream, "account_id",
|
|
|
|
snap->accts[i]->acct_id);
|
2023-03-14 15:51:50 +10:30
|
|
|
json_add_amount_msat(stream, "balance_msat",
|
|
|
|
snap->accts[i]->balance);
|
2021-12-13 16:44:32 -06:00
|
|
|
json_add_string(stream, "coin_type", snap->accts[i]->bip173_name);
|
|
|
|
json_object_end(stream);
|
|
|
|
}
|
|
|
|
json_array_end(stream);
|
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(balance_snapshot);
|
2021-12-13 16:44:32 -06:00
|
|
|
|
|
|
|
void notify_balance_snapshot(struct lightningd *ld,
|
|
|
|
const struct balance_snapshot *snap)
|
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("balance_snapshot");
|
|
|
|
balance_snapshot_serialize(n->stream, snap);
|
|
|
|
notify_send(ld, n);
|
2021-12-13 16:44:32 -06:00
|
|
|
}
|
|
|
|
|
2023-06-27 19:27:39 -07:00
|
|
|
static void json_add_block_added_fields(struct json_stream *stream,
|
2024-03-20 11:17:52 +10:30
|
|
|
const struct block *block)
|
2022-09-09 09:48:31 -03:00
|
|
|
{
|
|
|
|
json_add_string(stream, "hash",
|
2024-03-20 11:17:52 +10:30
|
|
|
fmt_bitcoin_blkid(tmpctx, &block->blkid));
|
2022-09-09 09:48:31 -03:00
|
|
|
json_add_u32(stream, "height", block->height);
|
2023-06-27 19:27:39 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void block_added_notification_serialize(struct json_stream *stream,
|
2023-07-10 15:17:52 +09:30
|
|
|
struct lightningd *ld,
|
2024-01-25 08:19:20 +10:30
|
|
|
const struct block *block)
|
2023-06-27 19:27:39 -07:00
|
|
|
{
|
2024-01-25 10:58:55 +10:30
|
|
|
if (lightningd_deprecated_out_ok(ld, ld->deprecated_ok,
|
|
|
|
"block_added_notification", "block",
|
|
|
|
"v23.08", "v24.08")) {
|
2023-07-07 11:39:38 +09:30
|
|
|
json_object_start(stream, "block");
|
|
|
|
json_add_block_added_fields(stream, block);
|
|
|
|
json_object_end(stream);
|
|
|
|
}
|
2023-06-27 19:27:39 -07:00
|
|
|
json_object_start(stream, "block_added");
|
|
|
|
json_add_block_added_fields(stream, block);
|
2022-09-09 09:48:31 -03:00
|
|
|
json_object_end(stream);
|
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(block_added);
|
2022-09-09 09:48:31 -03:00
|
|
|
|
2022-09-12 17:43:54 -03:00
|
|
|
void notify_block_added(struct lightningd *ld,
|
|
|
|
const struct block *block)
|
2022-09-09 09:48:31 -03:00
|
|
|
{
|
|
|
|
struct jsonrpc_notification *n =
|
2022-09-12 17:43:54 -03:00
|
|
|
jsonrpc_notification_start(NULL, "block_added");
|
2024-01-25 08:19:20 +10:30
|
|
|
block_added_notification_serialize(n->stream, ld, block);
|
2022-09-09 09:48:31 -03:00
|
|
|
jsonrpc_notification_end(n);
|
|
|
|
plugins_notify(ld->plugins, take(n));
|
|
|
|
}
|
|
|
|
|
2020-10-08 17:21:20 -05:00
|
|
|
static void openchannel_peer_sigs_serialize(struct json_stream *stream,
|
|
|
|
const struct channel_id *cid,
|
|
|
|
const struct wally_psbt *psbt)
|
|
|
|
{
|
|
|
|
json_add_channel_id(stream, "channel_id", cid);
|
|
|
|
json_add_psbt(stream, "signed_psbt", psbt);
|
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(openchannel_peer_sigs);
|
2020-10-08 17:21:20 -05:00
|
|
|
|
|
|
|
void notify_openchannel_peer_sigs(struct lightningd *ld,
|
|
|
|
const struct channel_id *cid,
|
|
|
|
const struct wally_psbt *psbt)
|
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("openchannel_peer_sigs");
|
|
|
|
openchannel_peer_sigs_serialize(n->stream, cid, psbt);
|
|
|
|
notify_send(ld, n);
|
2020-10-08 17:21:20 -05:00
|
|
|
}
|
2020-12-17 15:28:51 -06:00
|
|
|
|
|
|
|
static void channel_open_failed_serialize(struct json_stream *stream,
|
|
|
|
const struct channel_id *cid)
|
|
|
|
{
|
|
|
|
json_add_channel_id(stream, "channel_id", cid);
|
|
|
|
}
|
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(channel_open_failed);
|
2020-12-17 15:28:51 -06:00
|
|
|
|
|
|
|
void notify_channel_open_failed(struct lightningd *ld,
|
|
|
|
const struct channel_id *cid)
|
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("channel_open_failed");
|
|
|
|
channel_open_failed_serialize(n->stream, cid);
|
|
|
|
notify_send(ld, n);
|
2020-12-17 15:28:51 -06:00
|
|
|
}
|
2021-09-03 19:46:18 +09:30
|
|
|
|
2024-01-25 08:19:20 +10:30
|
|
|
REGISTER_NOTIFICATION(shutdown);
|
2021-09-03 19:46:18 +09:30
|
|
|
|
|
|
|
bool notify_plugin_shutdown(struct lightningd *ld, struct plugin *p)
|
|
|
|
{
|
2024-01-25 08:19:20 +10:30
|
|
|
struct jsonrpc_notification *n = notify_start("shutdown");
|
2023-07-11 07:55:22 +09:30
|
|
|
json_object_end(n->stream);
|
2021-09-03 19:46:18 +09:30
|
|
|
jsonrpc_notification_end(n);
|
|
|
|
return plugin_single_notify(p, take(n));
|
|
|
|
}
|
2024-01-25 10:58:56 +10:30
|
|
|
|
|
|
|
bool notify_deprecated_oneshot(struct lightningd *ld,
|
|
|
|
struct plugin *p,
|
|
|
|
bool deprecated_ok)
|
|
|
|
{
|
|
|
|
struct jsonrpc_notification *n = notify_start("deprecated_oneshot");
|
|
|
|
json_add_bool(n->stream, "deprecated_ok", deprecated_ok);
|
|
|
|
json_object_end(n->stream);
|
|
|
|
jsonrpc_notification_end(n);
|
|
|
|
return plugin_single_notify(p, take(n));
|
|
|
|
}
|
|
|
|
REGISTER_NOTIFICATION(deprecated_oneshot);
|
2024-01-11 16:05:46 +01:00
|
|
|
|
|
|
|
static void log_notification_serialize(struct json_stream *stream,
|
|
|
|
const struct log_entry *l)
|
|
|
|
{
|
|
|
|
json_add_string(stream, "level", log_level_name(l->level));
|
|
|
|
json_add_timestr(stream, "time", l->time.ts);
|
|
|
|
json_add_timeiso(stream, "timestamp", l->time);
|
|
|
|
json_add_string(stream, "source", l->prefix->prefix);
|
|
|
|
json_add_string(stream, "log", l->log);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
REGISTER_NOTIFICATION(log);
|
|
|
|
|
|
|
|
void notify_log(struct lightningd *ld, const struct log_entry *l)
|
|
|
|
{
|
|
|
|
struct jsonrpc_notification *n = notify_start("log");
|
|
|
|
log_notification_serialize(n->stream, l);
|
|
|
|
notify_send(ld, n);
|
|
|
|
}
|