When connecting to a Tor node, Zap fails to parse the GetInfoResponse JSON, because its Lnrpc_GetInfoResponse struct does not know about those new fields. This results in a connection error - making it impossible to connect to Tor enabled nodes. I believe this is the reason for the connection problems that numerous people in #333 are reporting.
An obvious quick fix for this problem is to ignore unknown fields when decoding lnd's JSON responses. This is what this pull requests proposes. By ignoring unknown fields, I can successfully connect to my node again using the latest version of Zap from master.
👉 Obviously a better fix would be to regenerate Lnrpc_GetInfoResponse. I figured before I start diving into that I'll ask for your guys' opinion:
whether this makes sense generally
what you suggest as a way forward for this issue
Thanks for the great work you put into Zap so far and let me know what you think! 🙏
Motivation and Context
This change fixes an issue that prevents connecting to Tor nodes using Zap.
From my personal testing it looks like this addresses the connection problems reported in #333.
How Has This Been Tested?
I tried connecting to a Tor enabled node using a Zap build from master.
I received what seems to be the same errors reported in #333.
I placed error breakpoints in Xcode to verify the source of the connection problem.
JSON parsing errors reporting unknown fields for GetInfoResponse were thrown.
I enabled the option to ignore unknown fields for JSON decoding
I could successfully connect to the same Tor enabled node from step 1.
I do not believe that this has effects on other parts of the code, however as discussed above, a more durable fix compared to ignoring unknown fields would maybe be to regenerate the decoding code, adding the newest fields.
Screenshots
See #333 for screenshots of failed connection attempts. It's the same error I get using the latest AppStore version (0.5.0) of Zap.
After the change I can successfully connect to a Tor enabled node.
Click for screenshot 📸
Types of changes
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes. I think there are no tests yet for the Tor lnd rest interface.
Description
Recent versions of lnd have introduced new fields for the RPC
GetInfoResponse
message. Zap'sLnrpc_GetInfoResponse
struct seems to have been generated using lnd version 0.8.0.A diff for
GetInfoResponse
version v0.8.0-beta and v0.10.1-beta (most recent version) can be viewed here: v0.8.0-beta...v0.10.1-beta.In short, the new fields that have been introduced to
GetInfoResponse
are:commit_hash
: https://github.com/lightningnetwork/lnd/commit/91cd7e633ac29ac6b4321a2ed10f5c72b1227ff7features
: https://github.com/lightningnetwork/lnd/commit/b99a457dd029c7023376e267cda45486d018a20dWhen connecting to a Tor node, Zap fails to parse the
GetInfoResponse
JSON, because itsLnrpc_GetInfoResponse
struct does not know about those new fields. This results in a connection error - making it impossible to connect to Tor enabled nodes. I believe this is the reason for the connection problems that numerous people in #333 are reporting.An obvious quick fix for this problem is to ignore unknown fields when decoding lnd's JSON responses. This is what this pull requests proposes. By ignoring unknown fields, I can successfully connect to my node again using the latest version of Zap from master.
👉 Obviously a better fix would be to regenerate
Lnrpc_GetInfoResponse
. I figured before I start diving into that I'll ask for your guys' opinion:Thanks for the great work you put into Zap so far and let me know what you think! 🙏
Motivation and Context
How Has This Been Tested?
GetInfoResponse
were thrown.I do not believe that this has effects on other parts of the code, however as discussed above, a more durable fix compared to ignoring unknown fields would maybe be to regenerate the decoding code, adding the newest fields.
Screenshots
Click for screenshot 📸
Types of changes
Checklist: