Uh oh!
There was an error while loading. Please reload this page.
feat: notification channel_state_changed - #4020
Conversation
3ff0d64 to
5c4432bComparefiatjaf
commented
Sep 8, 2020
How impossible would it be to have the reason of a channel state change? Is there such a concept? |
898bd51 to
cfdeab6Comparecdecker
commented
Sep 9, 2020
We currently only produce logs with the specifics, but we should be able to enumerate the possible causes and pass them in. I think this is a great idea, both for this hook as well as for the status in |
cdecker
commented
Sep 9, 2020
Opened #4027 to track this, and brainstorm how these details could look like. |
rustyrussell
commented
Sep 9, 2020
Ack cfdeab6 |
Uh oh!
There was an error while loading. Please reload this page.
This notification will be raised whenever a channel state changes.
The payload includes the channel and peer identifiers and the
old and the new state.
Example payload:
```
{
"channel_state_changed": {
"peer_id": "03bc9337c7a28bb784d67742ebedd30a93bacdf7e4ca16436ef3798000242b2251",
"channel_id": "a2d0851832f0e30a0cf778a826d72f077ca86b69f72677e0267f23f63a0599b4",
"short_channel_id" : "561820x1020x1",
"old_state": "CHANNELD_NORMAL",
"new_state": "AWAITING_UNILATERAL"
}
}
```
Changelog-Added: Plugins: channel_state_changed notificationcfdeab6 to
6fc4f2fComparecdecker
commented
Sep 9, 2020
LGTM ACK 6fc4f2f |
Note: Pipeline #20 currently ends up in "The job exceeded the maximum time limit for jobs, and has been terminated." |
Summary
This adds a new plugin notification message
channel_state_changedthat is called when a channel changes its state.This PR contains code, test and doc.
Addresses #4018
Example message
{ "channel_state_changed": { "peer_id": "03bc9337c7a28bb784d67742ebedd30a93bacdf7e4ca16436ef3798000242b2251", "channel_id": "a2d0851832f0e30a0cf778a826d72f077ca86b69f72677e0267f23f63a0599b4", "short_channel_id" : "561820x1020x1", "old_state": "CHANNELD_NORMAL", "new_state": "CHANNELD_SHUTTING_DOWN" } }Future thoughts
@fiatjaf added the question if it would be possible to have some kind of a 'reason' for a state changed operation. From a user or plugin developer perspective, this is mostly the distinction if a channel was closed by remote or by the user or for other (internal) reasons. We could add an string indication to this event, i.e.
"reason" : "USER"or"reason" : "REMOTE"or"reason" : "OTHER". Also, this only makes sens for state changes from CHANNELD_NORMAL to some CLOSING state. Maybe AWAITING_LOCKIN can also be caused by the user if its a local funding thats ongoing.Note
When unilaterally closing a channel it happens that the state changes two times to the same value
AWAITING_UNILATERAL.I don't think this is intended, but current test reflect that.