You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

303 lines
9.5 KiB

#include <ccan/array_size/array_size.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 { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;103x1x1&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;settled&#34;, &#34;received_time&#34;: 1560696342.368, &#34;resolved_time&#34;: 1560696342.556 } } ``` or ```json { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;110x1x0&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;local_failed&#34;, &#34;failcode&#34;: 16392, &#34;failreason&#34;: &#34;WIRE_PERMANENT_CHANNEL_FAILURE&#34;, &#34;received_time&#34;: 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&#39;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&#39;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&#39;t related to us, so we aren&#39;t accessed to the fail reason. `failed` must be set after `offered`. - `failed` case doesn&#39;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].
6 years ago
#include <lightningd/channel.h>
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 { &#34;warning&#34;: { &#34;level&#34;: &#34;warn&#34;, &#34;time&#34;: &#34;1559743608.565342521&#34;, &#34;source&#34;: &#34;lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:&#34;, &#34;log&#34;: &#34;Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg&#34; } } ``` 1. `level` is `warn` or `error`: `warn` means something seems bad happened and it&#39;s under control, but we&#39;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: `&lt;node_id&gt; chan #&lt;db_id_of_channel&gt;:`, `lightningd(&lt;lightningd_pid&gt;):`, `plugin-&lt;plugin_name&gt;:`, `&lt;daemon_name&gt;(&lt;daemon_pid&gt;):`, `jsonrpc:`, `jcon fd &lt;error_fd_to_jsonrpc&gt;:`, `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&#39;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;
6 years ago
#include <lightningd/json.h>
#include <lightningd/notification.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 { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;103x1x1&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;settled&#34;, &#34;received_time&#34;: 1560696342.368, &#34;resolved_time&#34;: 1560696342.556 } } ``` or ```json { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;110x1x0&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;local_failed&#34;, &#34;failcode&#34;: 16392, &#34;failreason&#34;: &#34;WIRE_PERMANENT_CHANNEL_FAILURE&#34;, &#34;received_time&#34;: 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&#39;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&#39;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&#39;t related to us, so we aren&#39;t accessed to the fail reason. `failed` must be set after `offered`. - `failed` case doesn&#39;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].
6 years ago
#include <lightningd/peer_htlcs.h>
static struct notification *find_notification_by_topic(const char* topic)
{
static struct notification **notilist = NULL;
static size_t num_notis;
if (!notilist)
notilist = autodata_get(notifications, &num_notis);
for (size_t i=0; i<num_notis; i++)
if (streq(notilist[i]->topic, topic))
return notilist[i];
return NULL;
}
bool notifications_have_topic(const char *topic)
{
struct notification *noti = find_notification_by_topic(topic);
if (noti)
return true;
return false;
}
static void connect_notification_serialize(struct json_stream *stream,
struct node_id *nodeid,
struct wireaddr_internal *addr)
{
json_add_node_id(stream, "id", nodeid);
json_add_address_internal(stream, "address", addr);
}
REGISTER_NOTIFICATION(connect,
connect_notification_serialize);
void notify_connect(struct lightningd *ld, struct node_id *nodeid,
struct wireaddr_internal *addr)
{
void (*serialize)(struct json_stream *,
struct node_id *,
struct wireaddr_internal *) = connect_notification_gen.serialize;
struct jsonrpc_notification *n
= jsonrpc_notification_start(NULL, connect_notification_gen.topic);
serialize(n->stream, nodeid, addr);
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}
static void disconnect_notification_serialize(struct json_stream *stream,
struct node_id *nodeid)
{
json_add_node_id(stream, "id", nodeid);
}
REGISTER_NOTIFICATION(disconnect,
disconnect_notification_serialize);
void notify_disconnect(struct lightningd *ld, struct node_id *nodeid)
{
void (*serialize)(struct json_stream *,
struct node_id *) = disconnect_notification_gen.serialize;
struct jsonrpc_notification *n
= jsonrpc_notification_start(NULL, disconnect_notification_gen.topic);
serialize(n->stream, nodeid);
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 { &#34;warning&#34;: { &#34;level&#34;: &#34;warn&#34;, &#34;time&#34;: &#34;1559743608.565342521&#34;, &#34;source&#34;: &#34;lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:&#34;, &#34;log&#34;: &#34;Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg&#34; } } ``` 1. `level` is `warn` or `error`: `warn` means something seems bad happened and it&#39;s under control, but we&#39;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: `&lt;node_id&gt; chan #&lt;db_id_of_channel&gt;:`, `lightningd(&lt;lightningd_pid&gt;):`, `plugin-&lt;plugin_name&gt;:`, `&lt;daemon_name&gt;(&lt;daemon_pid&gt;):`, `jsonrpc:`, `jcon fd &lt;error_fd_to_jsonrpc&gt;:`, `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&#39;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;
6 years ago
/*'warning' is based on LOG_UNUSUAL/LOG_BROKEN level log
*(in plugin module, they're 'warn'/'error' level). */
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 { &#34;warning&#34;: { &#34;level&#34;: &#34;warn&#34;, &#34;time&#34;: &#34;1559743608.565342521&#34;, &#34;source&#34;: &#34;lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:&#34;, &#34;log&#34;: &#34;Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg&#34; } } ``` 1. `level` is `warn` or `error`: `warn` means something seems bad happened and it&#39;s under control, but we&#39;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: `&lt;node_id&gt; chan #&lt;db_id_of_channel&gt;:`, `lightningd(&lt;lightningd_pid&gt;):`, `plugin-&lt;plugin_name&gt;:`, `&lt;daemon_name&gt;(&lt;daemon_pid&gt;):`, `jsonrpc:`, `jcon fd &lt;error_fd_to_jsonrpc&gt;:`, `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&#39;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;
6 years ago
{
json_object_start(stream, "warning");
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 { &#34;warning&#34;: { &#34;level&#34;: &#34;warn&#34;, &#34;time&#34;: &#34;1559743608.565342521&#34;, &#34;source&#34;: &#34;lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:&#34;, &#34;log&#34;: &#34;Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg&#34; } } ``` 1. `level` is `warn` or `error`: `warn` means something seems bad happened and it&#39;s under control, but we&#39;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: `&lt;node_id&gt; chan #&lt;db_id_of_channel&gt;:`, `lightningd(&lt;lightningd_pid&gt;):`, `plugin-&lt;plugin_name&gt;:`, `&lt;daemon_name&gt;(&lt;daemon_pid&gt;):`, `jsonrpc:`, `jcon fd &lt;error_fd_to_jsonrpc&gt;:`, `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&#39;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;
6 years ago
/* 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
* plugin to eliminate this misunderstanding.
*/
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 { &#34;warning&#34;: { &#34;level&#34;: &#34;warn&#34;, &#34;time&#34;: &#34;1559743608.565342521&#34;, &#34;source&#34;: &#34;lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:&#34;, &#34;log&#34;: &#34;Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg&#34; } } ``` 1. `level` is `warn` or `error`: `warn` means something seems bad happened and it&#39;s under control, but we&#39;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: `&lt;node_id&gt; chan #&lt;db_id_of_channel&gt;:`, `lightningd(&lt;lightningd_pid&gt;):`, `plugin-&lt;plugin_name&gt;:`, `&lt;daemon_name&gt;(&lt;daemon_pid&gt;):`, `jsonrpc:`, `jcon fd &lt;error_fd_to_jsonrpc&gt;:`, `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&#39;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;
6 years ago
l->level == LOG_BROKEN ? "error"
: "warn");
/* unsuaul/broken event is rare, plugin pay more attentions on
* the absolute time, like when channels failed. */
json_add_time(stream, "time", l->time.ts);
json_add_string(stream, "source", l->prefix);
json_add_string(stream, "log", l->log);
json_object_end(stream); /* .warning */
}
REGISTER_NOTIFICATION(warning,
warning_notification_serialize);
void notify_warning(struct lightningd *ld, struct log_entry *l)
{
void (*serialize)(struct json_stream *,
struct log_entry *) = warning_notification_gen.serialize;
struct jsonrpc_notification *n
= jsonrpc_notification_start(NULL, warning_notification_gen.topic);
serialize(n->stream, 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 { &#34;warning&#34;: { &#34;level&#34;: &#34;warn&#34;, &#34;time&#34;: &#34;1559743608.565342521&#34;, &#34;source&#34;: &#34;lightningd(17652): 0821f80652fb840239df8dc99205792bba2e559a05469915804c08420230e23c7c chan #7854:&#34;, &#34;log&#34;: &#34;Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: sent ERROR bad reestablish dataloss msg&#34; } } ``` 1. `level` is `warn` or `error`: `warn` means something seems bad happened and it&#39;s under control, but we&#39;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: `&lt;node_id&gt; chan #&lt;db_id_of_channel&gt;:`, `lightningd(&lt;lightningd_pid&gt;):`, `plugin-&lt;plugin_name&gt;:`, `&lt;daemon_name&gt;(&lt;daemon_pid&gt;):`, `jsonrpc:`, `jcon fd &lt;error_fd_to_jsonrpc&gt;:`, `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&#39;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;
6 years ago
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}
static void invoice_payment_notification_serialize(struct json_stream *stream,
struct amount_msat amount,
struct preimage preimage,
const struct json_escape *label)
{
json_object_start(stream, "invoice_payment");
json_add_string(stream, "msat",
type_to_string(tmpctx, struct amount_msat, &amount));
json_add_hex(stream, "preimage", &preimage, sizeof(preimage));
json_add_escaped_string(stream, "label", label);
json_object_end(stream);
}
REGISTER_NOTIFICATION(invoice_payment,
invoice_payment_notification_serialize)
void notify_invoice_payment(struct lightningd *ld, struct amount_msat amount,
struct preimage preimage, const struct json_escape *label)
{
void (*serialize)(struct json_stream *,
struct amount_msat,
struct preimage,
const struct json_escape *) = invoice_payment_notification_gen.serialize;
struct jsonrpc_notification *n
= jsonrpc_notification_start(NULL, invoice_payment_notification_gen.topic);
serialize(n->stream, amount, preimage, label);
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}
static void channel_opened_notification_serialize(struct json_stream *stream,
struct node_id *node_id,
struct amount_sat *funding_sat,
struct bitcoin_txid *funding_txid,
bool *funding_locked)
{
json_object_start(stream, "channel_opened");
json_add_node_id(stream, "id", node_id);
json_add_amount_sat_only(stream, "amount", *funding_sat);
json_add_txid(stream, "funding_txid", funding_txid);
json_add_bool(stream, "funding_locked", funding_locked);
json_object_end(stream);
}
REGISTER_NOTIFICATION(channel_opened,
channel_opened_notification_serialize)
void notify_channel_opened(struct lightningd *ld, struct node_id *node_id,
struct amount_sat *funding_sat, struct bitcoin_txid *funding_txid,
bool *funding_locked)
{
void (*serialize)(struct json_stream *,
struct node_id *,
struct amount_sat *,
struct bitcoin_txid *,
bool *) = channel_opened_notification_gen.serialize;
struct jsonrpc_notification *n
= jsonrpc_notification_start(NULL, channel_opened_notification_gen.topic);
serialize(n->stream, node_id, funding_sat, funding_txid, funding_locked);
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(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 { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;103x1x1&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;settled&#34;, &#34;received_time&#34;: 1560696342.368, &#34;resolved_time&#34;: 1560696342.556 } } ``` or ```json { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;110x1x0&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;local_failed&#34;, &#34;failcode&#34;: 16392, &#34;failreason&#34;: &#34;WIRE_PERMANENT_CHANNEL_FAILURE&#34;, &#34;received_time&#34;: 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&#39;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&#39;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&#39;t related to us, so we aren&#39;t accessed to the fail reason. `failed` must be set after `offered`. - `failed` case doesn&#39;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].
6 years ago
static void forward_event_notification_serialize(struct json_stream *stream,
const struct htlc_in *in,
const struct htlc_out *out,
enum forward_status state,
enum onion_type failcode,
struct timeabs *resolved_time)
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 { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;103x1x1&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;settled&#34;, &#34;received_time&#34;: 1560696342.368, &#34;resolved_time&#34;: 1560696342.556 } } ``` or ```json { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;110x1x0&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;local_failed&#34;, &#34;failcode&#34;: 16392, &#34;failreason&#34;: &#34;WIRE_PERMANENT_CHANNEL_FAILURE&#34;, &#34;received_time&#34;: 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&#39;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&#39;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&#39;t related to us, so we aren&#39;t accessed to the fail reason. `failed` must be set after `offered`. - `failed` case doesn&#39;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].
6 years ago
{
/* 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);
cur->channel_in = *in->key.channel->scid;
cur->msat_in = in->msat;
if (out) {
cur->channel_out = *out->key.channel->scid;
cur->msat_out = out->msat;
assert(amount_msat_sub(&cur->fee, in->msat, out->msat));
} else {
cur->channel_out.u64 = 0;
cur->msat_out = AMOUNT_MSAT(0);
cur->fee = AMOUNT_MSAT(0);
}
cur->payment_hash = tal_dup(cur, struct sha256, &in->payment_hash);
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 { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;103x1x1&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;settled&#34;, &#34;received_time&#34;: 1560696342.368, &#34;resolved_time&#34;: 1560696342.556 } } ``` or ```json { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;110x1x0&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;local_failed&#34;, &#34;failcode&#34;: 16392, &#34;failreason&#34;: &#34;WIRE_PERMANENT_CHANNEL_FAILURE&#34;, &#34;received_time&#34;: 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&#39;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&#39;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&#39;t related to us, so we aren&#39;t accessed to the fail reason. `failed` must be set after `offered`. - `failed` case doesn&#39;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].
6 years ago
cur->status = state;
cur->failcode = failcode;
cur->received_time = in->received_time;
cur->resolved_time = tal_steal(cur, resolved_time);
json_format_forwarding_object(stream, "forward_event", cur);
}
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 { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;103x1x1&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;settled&#34;, &#34;received_time&#34;: 1560696342.368, &#34;resolved_time&#34;: 1560696342.556 } } ``` or ```json { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;110x1x0&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;local_failed&#34;, &#34;failcode&#34;: 16392, &#34;failreason&#34;: &#34;WIRE_PERMANENT_CHANNEL_FAILURE&#34;, &#34;received_time&#34;: 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&#39;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&#39;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&#39;t related to us, so we aren&#39;t accessed to the fail reason. `failed` must be set after `offered`. - `failed` case doesn&#39;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].
6 years ago
REGISTER_NOTIFICATION(forward_event,
forward_event_notification_serialize);
void notify_forward_event(struct lightningd *ld,
const struct htlc_in *in,
const struct htlc_out *out,
enum forward_status state,
enum onion_type failcode,
struct timeabs *resolved_time)
{
void (*serialize)(struct json_stream *,
const struct htlc_in *,
const struct htlc_out *,
enum forward_status,
enum onion_type,
struct timeabs *) = forward_event_notification_gen.serialize;
struct jsonrpc_notification *n
= jsonrpc_notification_start(NULL, forward_event_notification_gen.topic);
serialize(n->stream, in, out, state, failcode, resolved_time);
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 { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;f5a6a059a25d1e329d9b094aeeec8c2191ca037d3f5b0662e21ae850debe8ea2&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;103x1x1&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;settled&#34;, &#34;received_time&#34;: 1560696342.368, &#34;resolved_time&#34;: 1560696342.556 } } ``` or ```json { &#34;forward_event&#34;: { &#34;payment_hash&#34;: &#34;ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff&#34;, &#34;in_channel&#34;: &#34;103x2x1&#34;, &#34;out_channel&#34;: &#34;110x1x0&#34;, &#34;in_msatoshi&#34;: 100001001, &#34;in_msat&#34;: &#34;100001001msat&#34;, &#34;out_msatoshi&#34;: 100000000, &#34;out_msat&#34;: &#34;100000000msat&#34;, &#34;fee&#34;: 1001, &#34;fee_msat&#34;: &#34;1001msat&#34;, &#34;status&#34;: &#34;local_failed&#34;, &#34;failcode&#34;: 16392, &#34;failreason&#34;: &#34;WIRE_PERMANENT_CHANNEL_FAILURE&#34;, &#34;received_time&#34;: 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&#39;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&#39;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&#39;t related to us, so we aren&#39;t accessed to the fail reason. `failed` must be set after `offered`. - `failed` case doesn&#39;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].
6 years ago
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}
static void sendpay_success_notification_serialize(struct json_stream *stream,
const struct wallet_payment *payment)
{
json_object_start(stream, "sendpay_success");
json_add_payment_fields(stream, payment);
json_object_end(stream); /* .sendpay_success */
}
REGISTER_NOTIFICATION(sendpay_success,
sendpay_success_notification_serialize);
void notify_sendpay_success(struct lightningd *ld,
const struct wallet_payment *payment)
{
void (*serialize)(struct json_stream *,
const struct wallet_payment *) = sendpay_success_notification_gen.serialize;
struct jsonrpc_notification *n =
jsonrpc_notification_start(NULL, "sendpay_success");
serialize(n->stream, payment);
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}
plugin: Another new notification type, &#39;sendpay_failure&#39; (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 { &#34;sendpay_failure&#34;: { &#34;code&#34;: 204, &#34;message&#34;: &#34;failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)&#34;, &#34;data&#34;: { &#34;id&#34;: 2, &#34;payment_hash&#34;: &#34;9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851&#34;, &#34;destination&#34;: &#34;035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d&#34;, &#34;msatoshi&#34;: 100000000, &#34;amount_msat&#34;: &#34;100000000msat&#34;, &#34;msatoshi_sent&#34;: 100001001, &#34;amount_sent_msat&#34;: &#34;100001001msat&#34;, &#34;created_at&#34;: 1561395134, &#34;status&#34;: &#34;failed&#34;, &#34;erring_index&#34;: 1, &#34;failcode&#34;: 16394, &#34;failcodename&#34;: &#34;WIRE_UNKNOWN_NEXT_PEER&#34;, &#34;erring_node&#34;: &#34;022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59&#34;, &#34;erring_channel&#34;: &#34;103x2x1&#34;, &#34;erring_direction&#34;: 0 } } } ``` `sendpay` doesn&#39;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.
6 years ago
static void sendpay_failure_notification_serialize(struct json_stream *stream,
const struct wallet_payment *payment,
int pay_errcode,
const struct onionreply *onionreply,
plugin: Another new notification type, &#39;sendpay_failure&#39; (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 { &#34;sendpay_failure&#34;: { &#34;code&#34;: 204, &#34;message&#34;: &#34;failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)&#34;, &#34;data&#34;: { &#34;id&#34;: 2, &#34;payment_hash&#34;: &#34;9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851&#34;, &#34;destination&#34;: &#34;035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d&#34;, &#34;msatoshi&#34;: 100000000, &#34;amount_msat&#34;: &#34;100000000msat&#34;, &#34;msatoshi_sent&#34;: 100001001, &#34;amount_sent_msat&#34;: &#34;100001001msat&#34;, &#34;created_at&#34;: 1561395134, &#34;status&#34;: &#34;failed&#34;, &#34;erring_index&#34;: 1, &#34;failcode&#34;: 16394, &#34;failcodename&#34;: &#34;WIRE_UNKNOWN_NEXT_PEER&#34;, &#34;erring_node&#34;: &#34;022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59&#34;, &#34;erring_channel&#34;: &#34;103x2x1&#34;, &#34;erring_direction&#34;: 0 } } } ``` `sendpay` doesn&#39;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.
6 years ago
const struct routing_failure *fail,
char *errmsg)
{
json_object_start(stream, "sendpay_failure");
/* In line with the format of json error returned
* by sendpay_fail(). */
json_add_member(stream, "code", false, "%d", pay_errcode);
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 */
json_object_end(stream); /* .sendpay_failure */
}
REGISTER_NOTIFICATION(sendpay_failure,
sendpay_failure_notification_serialize);
void notify_sendpay_failure(struct lightningd *ld,
const struct wallet_payment *payment,
int pay_errcode,
const struct onionreply *onionreply,
plugin: Another new notification type, &#39;sendpay_failure&#39; (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 { &#34;sendpay_failure&#34;: { &#34;code&#34;: 204, &#34;message&#34;: &#34;failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)&#34;, &#34;data&#34;: { &#34;id&#34;: 2, &#34;payment_hash&#34;: &#34;9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851&#34;, &#34;destination&#34;: &#34;035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d&#34;, &#34;msatoshi&#34;: 100000000, &#34;amount_msat&#34;: &#34;100000000msat&#34;, &#34;msatoshi_sent&#34;: 100001001, &#34;amount_sent_msat&#34;: &#34;100001001msat&#34;, &#34;created_at&#34;: 1561395134, &#34;status&#34;: &#34;failed&#34;, &#34;erring_index&#34;: 1, &#34;failcode&#34;: 16394, &#34;failcodename&#34;: &#34;WIRE_UNKNOWN_NEXT_PEER&#34;, &#34;erring_node&#34;: &#34;022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59&#34;, &#34;erring_channel&#34;: &#34;103x2x1&#34;, &#34;erring_direction&#34;: 0 } } } ``` `sendpay` doesn&#39;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.
6 years ago
const struct routing_failure *fail,
const char *errmsg)
plugin: Another new notification type, &#39;sendpay_failure&#39; (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 { &#34;sendpay_failure&#34;: { &#34;code&#34;: 204, &#34;message&#34;: &#34;failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)&#34;, &#34;data&#34;: { &#34;id&#34;: 2, &#34;payment_hash&#34;: &#34;9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851&#34;, &#34;destination&#34;: &#34;035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d&#34;, &#34;msatoshi&#34;: 100000000, &#34;amount_msat&#34;: &#34;100000000msat&#34;, &#34;msatoshi_sent&#34;: 100001001, &#34;amount_sent_msat&#34;: &#34;100001001msat&#34;, &#34;created_at&#34;: 1561395134, &#34;status&#34;: &#34;failed&#34;, &#34;erring_index&#34;: 1, &#34;failcode&#34;: 16394, &#34;failcodename&#34;: &#34;WIRE_UNKNOWN_NEXT_PEER&#34;, &#34;erring_node&#34;: &#34;022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59&#34;, &#34;erring_channel&#34;: &#34;103x2x1&#34;, &#34;erring_direction&#34;: 0 } } } ``` `sendpay` doesn&#39;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.
6 years ago
{
void (*serialize)(struct json_stream *,
const struct wallet_payment *,
int,
const struct onionreply *,
plugin: Another new notification type, &#39;sendpay_failure&#39; (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 { &#34;sendpay_failure&#34;: { &#34;code&#34;: 204, &#34;message&#34;: &#34;failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)&#34;, &#34;data&#34;: { &#34;id&#34;: 2, &#34;payment_hash&#34;: &#34;9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851&#34;, &#34;destination&#34;: &#34;035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d&#34;, &#34;msatoshi&#34;: 100000000, &#34;amount_msat&#34;: &#34;100000000msat&#34;, &#34;msatoshi_sent&#34;: 100001001, &#34;amount_sent_msat&#34;: &#34;100001001msat&#34;, &#34;created_at&#34;: 1561395134, &#34;status&#34;: &#34;failed&#34;, &#34;erring_index&#34;: 1, &#34;failcode&#34;: 16394, &#34;failcodename&#34;: &#34;WIRE_UNKNOWN_NEXT_PEER&#34;, &#34;erring_node&#34;: &#34;022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59&#34;, &#34;erring_channel&#34;: &#34;103x2x1&#34;, &#34;erring_direction&#34;: 0 } } } ``` `sendpay` doesn&#39;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.
6 years ago
const struct routing_failure *,
const char *) = sendpay_failure_notification_gen.serialize;
plugin: Another new notification type, &#39;sendpay_failure&#39; (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 { &#34;sendpay_failure&#34;: { &#34;code&#34;: 204, &#34;message&#34;: &#34;failed: WIRE_UNKNOWN_NEXT_PEER (reply from remote)&#34;, &#34;data&#34;: { &#34;id&#34;: 2, &#34;payment_hash&#34;: &#34;9036e3bdbd2515f1e653cb9f22f8e4c49b73aa2c36e937c926f43e33b8db8851&#34;, &#34;destination&#34;: &#34;035d2b1192dfba134e10e540875d366ebc8bc353d5aa766b80c090b39c3a5d885d&#34;, &#34;msatoshi&#34;: 100000000, &#34;amount_msat&#34;: &#34;100000000msat&#34;, &#34;msatoshi_sent&#34;: 100001001, &#34;amount_sent_msat&#34;: &#34;100001001msat&#34;, &#34;created_at&#34;: 1561395134, &#34;status&#34;: &#34;failed&#34;, &#34;erring_index&#34;: 1, &#34;failcode&#34;: 16394, &#34;failcodename&#34;: &#34;WIRE_UNKNOWN_NEXT_PEER&#34;, &#34;erring_node&#34;: &#34;022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59&#34;, &#34;erring_channel&#34;: &#34;103x2x1&#34;, &#34;erring_direction&#34;: 0 } } } ``` `sendpay` doesn&#39;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.
6 years ago
struct jsonrpc_notification *n =
jsonrpc_notification_start(NULL, "sendpay_failure");
serialize(n->stream, payment, pay_errcode, onionreply, fail, errmsg);
jsonrpc_notification_end(n);
plugins_notify(ld->plugins, take(n));
}