Add /status endpoint to signer
#4280
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## next #4280 +/- ##
==========================================
- Coverage 83.37% 83.08% -0.29%
==========================================
Files 434 434
Lines 308750 308770 +20
==========================================
- Hits 257419 256541 -878
- Misses 51331 52229 +898 ☔ View full report in Codecov by Sentry. |
|
If you see value in having this, I have no problem with it. It can always be removed later if we change our mind. |
| @@ -211,6 +213,13 @@ impl EventReceiver for SignerEventReceiver { | |||
| return Err(EventError::Terminated); | |||
| } | |||
|
|
|||
| if request.url() == "/status" { | |||
There was a problem hiding this comment.
To be clear, this is a POST not a GET, right? These are events that are POSTed by the node to the signer's event observer client.
There was a problem hiding this comment.
In this code it would respond to both GET and POST, though I have no problem keeping it to just GET. This is for the signer's event receiver, but the goal is to have a status endpoint for monitoring, which is why GET made sense.
This does "pollute" the event receiver, but the alternative is to have a separate endpoint/port to listen on for monitoring, if we want to have some kind of automated status check.
hstove
force-pushed
the
feat/signer-status-endpoint
branch
from
3958461 to
c312222
Compare
hstove
force-pushed
the
feat/signer-status-endpoint
branch
from
c312222 to
28a459a
Compare
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I've been documenting the workflow for running the signer, and I think it would be helpful to expose a
GET /statusendpoint to help setup and monitor the signer. This PR responds with200 OKfor that endpoint.Note that this could potentially conflict with an event observer path in the future. I'm not sure if the Stacks Blockchain API exposes a similar endpoint on the event receiver, but if so, we should follow use same route. @zone117x does that exist?
I could also imagine having an endpoint similar to
/v2/statuson the node, where more helpful state is returned, but I'm not sure how much we want to expose the fact that a specific IP is running a specific signer.