Skip to content
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

Return 415 if content type is not supported #26

Closed
nflaig opened this issue May 28, 2024 · 5 comments
Closed

Return 415 if content type is not supported #26

nflaig opened this issue May 28, 2024 · 5 comments

Comments

@nflaig
Copy link

nflaig commented May 28, 2024

I am running some interop tests with Lodestar <> Grandine on a feature branch of Lodestar which uses ssz for almost all apis. I noticed that Grandine does complain about the unsupported content type (as expected) but it returns a 400 error instead of 415.

May-27 18:51:01.289[]                �[31merror�[39m: Failed to download SyncDuties epoch=0 - getSyncCommitteeDuties failed with status 400: invalid validator index: Expected request with `Content-Type: application/json`: Expected request with `Content-Type: application/json`
Error: getSyncCommitteeDuties failed with status 400: invalid validator index: Expected request with `Content-Type: application/json`: Expected request with `Content-Type: application/json`

On the Lodestar side, we check the status code, and if it's a 415 we would retry the request with JSON and cache that ssz is not supported for this route, but since Grandine return a 400 status code, the request just fails.

Note, we will use JSON by default if the spec does not specify that the API should support SSZ but it would still be great to have to fallback mechanism in place in case a user overrides the default behavior to always sent SSZ for all apis.

SifraiTeam pushed a commit to grandinetech/grandine-snapshot-tests that referenced this issue Jun 14, 2024
SifraiTeam pushed a commit that referenced this issue Jun 18, 2024
axum::Json already does that, but our EthJson and Error were replacing its status codes with 400.
The solution was to store JsonRejection directly in Error and delegate to it in Error::status_code.
Doing so also makes endpoints return status codes 413 and 422 when appropriate.

The duplicated rejection messages came up again.
We were able to determine the cause and come up with a better workaround this time.
The issue should be fixed for query strings too.
SifraiTeam pushed a commit that referenced this issue Jun 18, 2024
axum::Json already does that, but our EthJson and Error were replacing its status codes with 400.
The solution was to store JsonRejection directly in Error and delegate to it in Error::status_code.
Doing so also makes endpoints return status codes 413 and 422 when appropriate.

The duplicated rejection messages came up again.
We were able to determine the cause and come up with a better workaround this time.
The issue should be fixed for query strings too.
SifraiTeam pushed a commit that referenced this issue Jul 12, 2024
axum::Json already does that, but our EthJson and Error were replacing its status codes with 400.
The solution was to store JsonRejection directly in Error and delegate to it in Error::status_code.
Doing so also makes endpoints return status codes 413 and 422 when appropriate.

The duplicated rejection messages came up again.
We were able to determine the cause and come up with a better workaround this time.
The issue should be fixed for query strings too.
@Tumas
Copy link
Member

Tumas commented Jul 16, 2024

hey @nflaig, did you have the chance to test this? Fix has been merged to develop.

@nflaig
Copy link
Author

nflaig commented Jul 16, 2024

Do you have an image I can use?

@sauliusgrigaitis
Copy link
Member

We don't build develop images, can you build it with the Dockerfile that is provided in the repo?

@nflaig
Copy link
Author

nflaig commented Jul 16, 2024

We don't build develop images, can you build it with the Dockerfile that is provided in the repo?

It looks like EF devops builds an image from your dev branch, I can use that one https://hub.docker.com/layers/ethpandaops/grandine/develop-minimal/images/sha256-5135f0aa0bbc82c4ad487a01cea520a86f2d5c6f9a44d5abb191659e67695fda?context=explore

@nflaig
Copy link
Author

nflaig commented Jul 16, 2024

Confirmed the fix by running the following config:

participants:
  - el_type: geth
    el_image: ethereum/client-go:stable
    cl_type: grandine
    cl_image: ethpandaops/grandine:develop-minimal
    vc_type: lodestar
    vc_image: nflaig/lodestar:post-validators
    vc_extra_params:
      - --http.requestWireFormat=ssz
    count: 4
network_params:
  genesis_delay: 60
  num_validator_keys_per_node: 64
additional_services:
  - assertoor
  - dora
snooper_enabled: true
disable_peer_scoring: true
assertoor_params:
  image: "ethpandaops/assertoor:master"
  run_stability_check: false
  run_block_proposal_check: false
  tests:
    - https://raw.githubusercontent.com/ethpandaops/assertoor-test/2a45f2f78dd2c336ac99bf15e61edc076f15ce67/assertoor-tests/block-proposal-check.yaml

Thanks for the fix 🙏

@nflaig nflaig closed this as completed Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants