Skip to content

Actually check, cleanup, notification schemas #8376

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

rustyrussell
Copy link
Contributor

We have schemas for (some) notifications, which GRPC seems to rely on, but they were completely untested. And thus, of course, wrong.

This does not work: the final change breaks GRPC! Help me @daywalker90 can you review final two commits especially?

  1. Deprecate "null" for channel_state_changed scid.
  2. Don't wrap plugin notifications in "payload", let them look like native.
  3. Make custom plugin notifications follow the "wrap fields in a subobject of same name".
  4. Add dev hook to dump hook & notification io into files in a given dir, and use it to post-process check that they match schemas.

Particularly important since we're going to update the format: this makes sure we don't break them!

Signed-off-by: Rusty Russell <[email protected]>
… in channel_state_changed notification

We always prefer to omit fields rather than use 'null' (or unknown!).

Note that before this, the schema was broken, so we have to put a special
exemption in for that case.

Signed-off-by: Rusty Russell <[email protected]>
Rather than forcing them to wrap their parameters in a "payload"
sub-object, copy in params directly.  We include the "origin" field
one level up, if they care.

The next patch restores compatibility for the one place we currently use
them, which is the pay plugin.

Signed-off-by: Rusty Russell <[email protected]>
…ame.

All the core notifications changed over to wrapping the notification
fields in an object with the name of the notification, but notifications
from plugins were missed.

Changelog-Added: Plugins: `channel_hint_update`, `pay_failure` and `pay_success` notifications now have objects of the same name containing the expected fields.
Changelog-Deprecated: Plugins: `channel_hint_update`, `pay_failure` and `pay_success` notification fields outside the same-named object.
Signed-off-by: Rusty Russell <[email protected]>
…ion schemas.

Note that we need a workaround for deprecated APIs where "channel_state_changed" output "null" which violated the schema.

Signed-off-by: Rusty Russell <[email protected]>
…ications.

Modern style for notifications is to put everything inside an object
of same name as the method.

For now this means duplication for backward compatibility.  ChatGPT
helped me do that.

Signed-off-by: Rusty Russell <[email protected]>
…t.json

This is done by tests/test_connection.py::test_websocket:

```
{
  "jsonrpc": "2.0",
  "method": "connect",
  "params": {
    "connect": {
      "id": "031b84c5567b126440995d3ed5aaba0565d71e1834604819ff9c17f5e9d5dd078f",
      "direction": "in",
      "address": {
        "type": "websocket",
        "subtype": "ipv4",
        "address": "127.0.0.1",
        "port": 59412
      }
    }
  }
}
```

Totally breaks all the GRPC code though.

Signed-off-by: Rusty Russell <[email protected]>
@rustyrussell rustyrussell added this to the v25.09 milestone Jun 26, 2025
@madelinevibes madelinevibes added the Status::Assigned The issue has been given to a team member for resolution. label Jun 26, 2025
@daywalker90
Copy link
Collaborator

daywalker90 commented Jun 26, 2025

Regarding the compile error with ConnectAddressType: Does the rpc method "connect" also have address type "websocket"? Right now the schema does not. The problem here is that both the rpc method and notification have the same path "connect" and so msggen is searching in the same path for the fields. Either the schemas have to match for "connect.address.type" or i have to submit a patch for mssgen.

@rustyrussell
Copy link
Contributor Author

Regarding the compile error with ConnectAddressType: Does the rpc method "connect" also have address type "websocket"? Right now the schema does not. The problem here is that both the rpc method and notification have the same path "connect" and so msggen is searching in the same path for the fields. Either the schemas have to match for "connect.address.type" or i have to submit a patch for mssgen.

Ah. We can't connect out to a web socket, so connect can't return that as type. Not sure what we want to do here; we could include it in connect for completeness, but it will never appear?

@daywalker90
Copy link
Collaborator

Ah. We can't connect out to a web socket, so connect can't return that as type. Not sure what we want to do here; we could include it in connect for completeness, but it will never appear?

Either that or https://github.com/daywalker90/lightning/tree/msggen-connect-notification-override

@rustyrussell
Copy link
Contributor Author

rustyrussell commented Jun 27, 2025

Here's the diff:

diff --git a/doc/schemas/notification/connect.json b/doc/schemas/notification/connect.json
index 8aaeb3eb8..1fbe9310f 100644
--- a/doc/schemas/notification/connect.json
+++ b/doc/schemas/notification/connect.json
@@ -53,7 +53,8 @@
               "ipv4",
               "ipv6",
               "torv2",
-              "torv3"
+              "torv3",
+              "websocket"
             ],
             "description": [
               "Type of connection (*torv2*/*torv3* only if **direction** is *out*)"

And here's the result with your commit applied:

rror[E0412]: cannot find type `ConnectAddressType` in this scope
   --> cln-rpc/src/notifications.rs:130:20
    |
130 |     pub item_type: ConnectAddressType,
    |                    ^^^^^^^^^^^^^^^^^^ not found in this scope
    |
help: consider importing this enum
    |
6   + use crate::model::responses::ConnectAddressType;
    |

error[E0412]: cannot find type `ConnectDirection` in this scope
   --> cln-rpc/src/notifications.rs:136:20
    |
47  | pub enum PeerConnectDirection {
    | ----------------------------- similarly named enum `PeerConnectDirection` defined here
...
136 |     pub direction: ConnectDirection,
    |                    ^^^^^^^^^^^^^^^^
    |
help: an enum with a similar name exists
    |
136 |     pub direction: PeerConnectDirection,
    |                    ~~~~~~~~~~~~~~~~~~~~
help: consider importing this enum
    |
6   + use crate::model::responses::ConnectDirection;
    |

For more information about this error, try `rustc --explain E0412`.
error: could not compile `cln-rpc` (lib) due to 2 previous errors
make: *** [plugins/Makefile:312: target/debug/clnrest] Error 101
make: *** Waiting for unfinished jobs....

@daywalker90
Copy link
Collaborator

Did you run make gen?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status::Assigned The issue has been given to a team member for resolution.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants