-
Notifications
You must be signed in to change notification settings - Fork 2.2k
chainrpc: return Unavailable while notifier starts #10352
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
base: master
Are you sure you want to change the base?
chainrpc: return Unavailable while notifier starts #10352
Conversation
From v0.20.0-rc3 (commit c6f458e) onward the ChainNotifier sub-server may still be initialising when clients attempt to subscribe, currently resulting in a gRPC Unknown error with a plain-text message. Change the notifier RPC endpoints to return codes.Unavailable instead so clients can reliably interpret the condition as "retry later" and handle the startup lag without unstable string matching.
d6c3e8f to
c165bae
Compare
lnd v0.20.0-rc3 delays ChainNotifier startup which causes Loop to hit "chain notifier RPC is still in the process of starting" during initial subscriptions (LND commit c6f458e478f9ef2cf1d394972bfbc512862c6707). Add a shared retry helper in lndclient so block epoch, confirmation and spend registrations transparently retry until the sub-server is ready, along with regression tests covering the behaviour. With lnd PR lightningnetwork/lnd#10352 the server now returns gRPC codes.Unavailable instead of codes.Unknown, so the helper accepts either signal (status code or a string).
lnd v0.20.0-rc3 delays ChainNotifier startup which causes Loop to hit "chain notifier RPC is still in the process of starting" during initial subscriptions (LND commit c6f458e478f9ef2cf1d394972bfbc512862c6707). Add a shared retry helper in lndclient so block epoch, confirmation and spend registrations transparently retry until the sub-server is ready, along with regression tests covering the behavior. With lnd PR lightningnetwork/lnd#10352 the server now returns gRPC codes.Unavailable instead of codes.Unknown, so the helper accepts either signal (status code or a string).
lnd v0.20.0-rc3 delays ChainNotifier startup which causes Loop to hit "chain notifier RPC is still in the process of starting" during initial subscriptions (LND commit c6f458e478f9ef2cf1d394972bfbc512862c6707). Add a shared retry helper in lndclient so block epoch, confirmation and spend registrations transparently retry until the sub-server is ready, along with regression tests covering the behavior. With lnd PR lightningnetwork/lnd#10352 the server now returns gRPC codes.Unavailable instead of codes.Unknown, so the helper accepts either signal (status code or a string).
Also fixed a typo in release notes.
c165bae to
e4313eb
Compare
|
Let's add motive behind that PR in the PR description. That can help give reviewers some context and perhaps getting some attraction. In other words referencing this: lightninglabs/lndclient#253 (comment) |
Great idea! I added Motivation section. |
ziggie1984
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you
ViktorT-11
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks 🙏
Change Description
From v0.20.0-rc3 (commit c6f458e) onward the ChainNotifier sub-server may still be initialising when clients attempt to subscribe, currently resulting in a gRPC Unknown error with a plain-text message. Change the notifier RPC endpoints to return codes.Unavailable instead so clients can reliably interpret the condition as "retry later" and handle the startup lag without unstable string matching.
Motivation
To ensure that Loop and other services wait for LND while it is starting up, lndclient was modified to retry when it encounters the "chain notifier RPC is still in the process of starting" error. @mohamedawnallah noted in the review that relying on matching error strings is not ideal. Using an error code on the other hand is more reliable. The purpose of this PR is to provide lndclient (and other clients) with a clear signal to retry the request. See lightninglabs/lndclient#253 (comment)
Steps to Test
Send
RegisterBlockEpochNtfnwhile LND is starting and inspect the returned gRPC error code. It should beUnavailable.Pull Request Checklist
Testing
Code Style and Documentation
[skip ci]in the commit message for small changes.📝 Please see our Contribution Guidelines for further guidance.