core/validatorapi: serve ssz for gloas endpoints

[KaloyanTanev]

Serves SSZ (application/octet-stream) responses when the validator client asks for them via the Accept header on the gloas endpoints POST /eth/v4/validator/blocks/{slot} and GET /eth/v1/validator/payload_attestation_data, and accepts SSZ request bodies on POST /eth/v1/beacon/pool/payload_attestations. The spec offers SSZ on all three; charon only spoke JSON, which broke prysm on locally built blocks (it requires the payload-included v4 response as SSZ and does not fall back) and cost lighthouse a 415 round trip on every payload attestation submission.

SSZ request bodies decode into the generated list types PayloadAttestationMessages and SignedProposerPreferencesList from go-eth2-client v0.29.0-obol.5-gloas (ObolNetwork/go-eth2-client#33), so the bump is included here. A malformed SSZ body is now a 400 rather than a 415.

category: bug
ticket: #4324

[codecov]

Codecov Report

❌ Patch coverage is 89.79592% with 5 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (gloas@ae2c2fb). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
core/validatorapi/router.go	89.79%	5 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             gloas    #4733   +/-   ##
========================================
  Coverage         ?   66.40%           
========================================
  Files            ?      247           
  Lines            ?    31952           
  Branches         ?        0           
========================================
  Hits             ?    21217           
  Misses           ?    10734           
  Partials         ?        1           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[OisinKyne]

Sharing the feedback inclusive of the merge order suggestion to minimise conflicts

#4733 — serve SSZ on the gloas endpoints: approve after two fixes

The SSZ encoding is right: the body is the bare BeaconBlock/BlockContents/PayloadAttestationData, and all the envelope fields go out as headers (version, payload-included, both values).

• 🚨 Breaks when merged with #4732. Both PRs rewrite writeResponse, and git merge-tree shows a conflict. #4732's noContentResponse doesn't implement MarshalSSZ. If whoever resolves the conflict puts the SSZ type switch first, a VC asking for SSZ payload attestation data on an empty slot gets a 500 ("response type doesn't support ssz marshalling") instead of a 204. The 204 check has to come before the encoding switch. Whichever lands second needs a test for "SSZ requested + no block".
• Overlaps with go-eth2-client #33 (the one you just approved). The generic unmarshalSSZList duplicates the generated PayloadAttestationMessages/SignedProposerPreferencesList types, and it skips the list-length limits those types enforce (PTC_SIZE = 512; 64 for preferences). submit_payload_attestations also has no MaxBody cap. Once #33 is tagged and charon picks it up, switch to the generated types and delete the helper. Until then, a MaxBody cap or item-count check is a cheap stopgap.
• Nit: negotiateResponseType uses strings.Contains on the Accept header, which ignores quality weights (q=). That's fine for the Accept headers VCs actually send today, but add a comment saying it's deliberate.

Suggested merge order: #4727 → #33 tag → #4733 (moved onto the generated types) → #4732 rebased on top, with the 204 check placed first in writeResponse.

[KaloyanTanev]

Rebased on gloas after #4732 merged. writeResponse keeps the 204 check ahead of the encoding switch, with a new payload_attestation_data_ssz_no_block test.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud