Config file validation only seems to check the source not the destination
Closed this issue · 8 comments
In the config file if I fat finger the source and have a pubkey that doesn't match a node specified earlier in the file I get a validation error (which is nice). If however I fat finger the destination I do not appear to get the same validation checks and instead get the error:
Error: Lightning Error: GetNodeInfoError("Get node info error status: NotFound, message: \"unable to find node\", details: [], metadata: MetadataMap { headers: {\"content-type\": \"application/grpc\"} }")
Caused by:
Get node info error Get node info error status: NotFound, message: "unable to find node", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc"} }
I just wanted to clarify that I believe this is a distinct issue from (#92) because in that situation the pubkey was wrong in the top node definition section too and it's not a validation issue.
When we add validation of destination, we should also include backoff to allow some amount of time for gossip to sync.
Error: Lightning Error: GetNodeInfoError("Get node info error status: NotFound, message: \"unable to find node\", details: [], metadata: MetadataMap { headers: {\"content-type\": \"application/grpc\"} }")
Caused by:
Get node info error Get node info error status: NotFound, message: "unable to find node", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc"} }
Error reported above comes from a call to check features of the destination node. It's a validation of destination, but we did a
poor job of reporting the validation error.
When we add validation of destination, we should also include backoff to allow some amount of time for gossip to sync.
Ack.
We already check features supported by destination but this assumes a well-synced network. How far can we go with this simple validation of destinations?
I just wanted to clarify that I believe this is a distinct issue from (#92) because in that situation the pubkey was wrong in the top node definition section too and it's not a validation issue.
Trying to repro this after #106 . I am convinced it's the same as #92 but ofc we need more validation for destinations
I might have misunderstood the need for validation of the destination pubkey.
As long as the source node has a connection to the destination node then the destination node doesn't need to be in the top of the configuration file?
I might have misunderstood the need for validation of the destination pubkey.
As long as the source node has a connection to the destination node then the destination node doesn't need to be in the top of the configuration file?
True. any node at the top of the file can be a source or destination. but any node can be a destination provided it's connected to the source and it has keysend
Our validation currently has two steps
- check that all sources are in the node section of the config (top of the file)
- check that all destinations support keysend