-
-
Notifications
You must be signed in to change notification settings - Fork 317
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
fix: add accept: application/json
header to remote signer requests and improve invalid response handling
#6587
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #6587 +/- ##
============================================
- Coverage 61.70% 61.69% -0.02%
============================================
Files 556 556
Lines 58799 58820 +21
Branches 1886 1887 +1
============================================
+ Hits 36283 36287 +4
- Misses 22475 22492 +17
Partials 41 41 |
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 @cnupy for looking into this, let's try to get this in our next release
I think there needs to be a general handler for text vs json response, this logic is basically the same across all three functions.
I think it is ok right now to have a fix we can include for Diva but long term we need to use a declarative API client as we do for other APIs in @lodestar/api
package and test it against the spec.
It would also good to make sure we test against Diva in our CI, there are already generic signer tests here
We would just have to extend this function
I can't tell how complex it is to run Diva like this, but would be awesome to test against |
Thanks for the feedback. This is actually my very first time writing anything in TypeScript, so please excuse me if I've messed up a few things. I will do my best to address all comments for now, and will be more than happy to help with the declarative API client in the near future (once I get more familiar with the codebase). |
Don't worry about that, this is a great PR to improve compatibility with Diva and also follow the spec, as we should have been supporting text responses already. Happy to assist on the PR to get it merged, and feel free to join our discord and ask any questions there as well
I am currently working on a major rework of the API client, it doesn't consider text responses right now as a wire format but could extend in the future. Happy to collaborate on that as well once it is ready |
…move error logging and improve exception messaging for res != OK; fix content type parsing and handling of invalid content types;
It shouldn't be hard to instantiate a Diva node container, but the actual testing might be harder than consensys/web3signer, as Diva is a distributed P2P remote signer and I'm not sure how to get it to sign a test message or return a test key store. Perhaps someone from Diva could help here. Generic tests against a pre-prepared response payloads might be easier to get the job done for now. |
Unless they have some sort of standalone or dev mode it will probably be hard based on how it is configured here. I have asked in their Discord if there is a simpler setup. |
…ty (response error)
Not much cooperation in Diva DVT discord, and their node/remotesigner is closed source for now. I guess not much can be done about that for now. |
I got a response but this is not possible in current release, they noted something about next release they might include it. Based on just this PR it feels like there is definitley some work that Diva has to do, e.g. return errors if something fails. It doesn't seem like it would be stable right now to include in our CI. I am ok with including a fix as long as we make sure web3signer is not impacted which we actively test against so should be fine there. |
Existing tests are passing so I think we are good on that front, if you have confirmed that Diva compatibility is fixed as well I think we can go ahead and merge this. Will do another review round locally, but this PR should be good to include in our next release. Thanks @cnupy for fast updates and helping us to be compatible with Diva :) |
I can confirm that I can successfully sign messages and submit attestations using Diva as a remote signer on Holesky. I'm still getting Thanks @nflaig for your support :) |
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 talking to the Diva team about the response format, and they already support json responses for all APIs as per spec but currently default to text/plain
if no Accept header is set. But mentioned this default behavior will be changed in the next release.
The main concern I have with the changes in this PR is that adding text/plain
support will make it harder to reuse the generic api client for the remote signer in the future. And to be spec compliant we also don't really need to implement handling text responses as we can just state in the Accept header that we only accept json. It is only required by the server to support both content type responses.
I would suggest the following
- make sure we set
accept: application/json
in all requests - explicitly validate
content-type
header in response and throw good error message if header is missing or format is unsupported (instead of some weird parsing errors) - include the error improvements to fall back to
res.statusText
ifres.text()
is empty
… error handling; add accept header to all requests;
All done and works as expected. |
Awesome, thanks for the fast update. I pushed some minor updates but those shouldn't change anything. You can review and approve then we should be good to merge this |
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.
Great. Thanks for correcting that.
woops, I broke json parsing but fixed now. Want to do some more debugging locally against web3signer to see how we handle those errors etc. If you make sure we work with Diva we are good to go 🚀 |
return JSON.parse(await res.text()) as T; | ||
function getErrorMessage(errBody: string): string { | ||
try { | ||
const errJson = JSON.parse(errBody) as {message: string}; |
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.
No idea why neither Web3Signer nor Diva return proper errors as json but I made this a bit more future proof to handle potential json errors.
The spec does not define an error schema so we can't be sure how remote signers implement this.
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 don't think it's a good idea to treat error response as json if it's not in the spec. Even if the error response is actually json, you are not guaranteed that there is a field named message
(it could be msg
, error
or even errorMsg
...) and the result will be worse than if you had included the response content as plain text. You may also need to check the content-type
of the error response before treating it as json. I know there is a try/catch block, but why do this if it's not in the spec?
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.
Ok fair, we would have to check content type and response format is unclear. Just assumed sane format similar to beacon api. Although for errors is not as critical to check proper format and have fallback logic via try/catch.
Let's keep error handling as is, the Diva team is working on the spec will ask them about it and see if we can standardize this a bit better.
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, thanks again @cnupy for the fast response cycles
accept: application/json
header to remote signer requests and improve invalid response handling
accept: application/json
header to remote signer requests and improve invalid response handlingaccept: application/json
header to remote signer requests and improve invalid response handling
🎉 This PR is included in v1.18.0 🎉 |
Motivation
Some Remote Signing Service implementations do not return by default response in application/json format and the signing fails.
Description
This pull request modifies externalSignerClient.ts to add the accept: application/json request header, instructing the remote signer to return the response as json.
Steps to test or reproduce
Reproducible using Diva DVT as remote signer.