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.
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
feat: Rest endoint /health for rln #2011
feat: Rest endoint /health for rln #2011
Changes from 4 commits
beb3cf5
b95c998
18a5a3f
72b4639
e1f37c4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Maybe a comment to indicate what
isReady()
indicates? Does it mean the node has completed setup procedures and is listening for new connections?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.
I will add as there is one little stuff to fix in test.
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.
unsure about the best practices of
health
endpoints, but would it make sense to return a json that we can extend in the future? In case we want more granularity on the state of the services. For example, we may want to say that is not healthy, but provide a list on which services are not healthy.No need to define it right now but allow for future extension. return json instead of textResponse?
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.
I can change it but in this case http status holds the information rather.
For meaningful message, text can be enough. Not sure what information we can structure into json later.
For checking status of different submodules or protocols sounds more like an admin interface than a health. Wdyt?
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.
yep indeed. http status code has the information.
i was suggesting to return a json in case we want to add more information in the future. so if for example its failing, you have information such as (example taken from prysm node): so you know which service is not healthy
no need to do it now, but be prepared to extend it.
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.
I was gonna add the same comment - let's use JSON rather than text - it is extensible and easier to process with tools than plain text
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.
I'm ok with it, but will do in a separate PR is possible.
Also I think we need to enhance a bit client decoders (not just here) to accept json/text both due error cases returns text type, mixing them can cause exception. It's on my list already, but will do in all rest endpoints where necessary.
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.
Unrelated to this issue, obviously, but since we are talking about it - would it make more sense to always return json (even for errors)?