feat: notification channel_state_changed#4020
Merged
rustyrussell merged 5 commits intoElementsProject:masterElementsProject/lightning:masterfrom Sep 10, 2020
m-schmoock:feat/notification_channel_state_changedm-schmoock/lightning:feat/notification_channel_state_changedCopy head branch name to clipboard
Merged
feat: notification channel_state_changed#4020rustyrussell merged 5 commits intoElementsProject:masterElementsProject/lightning:masterfrom m-schmoock:feat/notification_channel_state_changedm-schmoock/lightning:feat/notification_channel_state_changedCopy head branch name to clipboard
rustyrussell merged 5 commits intoElementsProject:masterElementsProject/lightning:masterfrom
m-schmoock:feat/notification_channel_state_changedm-schmoock/lightning:feat/notification_channel_state_changedCopy head branch name to clipboard
Conversation
3ff0d64 to
5c4432b
Compare
Contributor
|
How impossible would it be to have the reason of a channel state change? Is there such a concept? |
898bd51 to
cfdeab6
Compare
Member
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 |
4 tasks
Member
|
Opened #4027 to track this, and brainstorm how these details could look like. |
Contributor
|
Ack cfdeab6 |
rustyrussell
requested changes
Sep 9, 2020
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 notification
cfdeab6 to
6fc4f2f
Compare
Member
|
LGTM ACK 6fc4f2f |
Collaborator
Author
|
Note: Pipeline #20 currently ends up in "The job exceeded the maximum time limit for jobs, and has been terminated." |
rustyrussell
approved these changes
Sep 9, 2020
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.