Reward eth/v1/beacon/rewards/attestations/186303 RPC return 404

[J1a-wei]

Hi team, I encountered a very strange question. I checked the prater network validator's ATT reward one by one epoch. It can return the correct result in EPOCH 18302 and 18304, but it cannot return 404 at 18303.

Versions (Add all that apply)

Teku: v2.36.0

exec /opt/teku/bin/teku --network=prater --data-beacon-path=/data/teku/beacon --data-path=/data/teku --data-storage-archive-frequency=32 --data-storage-mode=archive --data-storage-non-canonical-blocks-enabled=false --ee-endpoint=http://ethereum-goerli-crcv7w92t3vm:8551 --ee-jwt-secret-file=/secret/jwtsecret --p2p-enabled=true --p2p-port=9000 --p2p-advertised-ip=$(POD_IP) --p2p-advertised-port=9000 --rest-api-enabled=true --rest-api-host-allowlist=* --rest-api-interface=0.0.0.0 --rest-api-port=8080 --rest-api-cors-origins=* --rest-api-docs-enabled=false

[rolfyone]

Thanks for raising, this is probably less likely to happen on mainnet but a short explanation might be a good start...

TL/DR: this is a bug in our processing.
A query for epoch 186303 is a miss in this instance which is because it's finding the last block of the next epoch (so slot 5961759)

It will be more correct for us to get the state rather than the block because a block can be missed where a state is always available (assuming we're in archive mode like you are).

We should call getBeaconStateAndMetadata rather than getBlockAndMetadata and update the handling accordingly (we can skip the state fetch inside the future processing then).

The upside of this change will be a (albeit slight) performance improvement.

[J1a-wei]

Hi @rolfyone , I encountered the same problem(eopch 211933) on the mainnet. Do we need to resync data after the fix? And how long will it take to fix? Thank u :)

[lucassaldanha]

Hi @rolfyone , I encountered the same problem(eopch 211933) on the mainnet. Do we need to resync data after the fix? And how long will it take to fix? Thank u :)

Hi! No need to resync after the fix, just updating your node. We expect to have the fix merged soon (1 - 2 days).