Canonical head locked by querying for future attestation data

[realbigsean]

Description

Querying the attestation_data with a future slot causes a CanonicalHeadLockTimeout in fork choice. The further in the future the slot, the longer the lock lasts.

Version

v0.3.0

Present Behaviour

This query created the lock for 20 mins for me:

curl 'localhost:5052/eth/v1/validator/attestation_data?slot=10000000&committee_index=1'

Oct 21 15:18:45.226 INFO New block received                      hash: 0xd7af…6eb7, slot: 562293
Oct 21 15:18:47.054 ERRO Fork choice failed                      location: block gossip, error: CanonicalHeadLockTimeout
Oct 21 15:18:50.001 INFO Synced                                  slot: 562293, block:    …  empty, epoch: 17571, finalized_epoch: 15614, finalized_root: 0xb380…b440, peers: 27, service: slot_notifier
Oct 21 15:19:02.001 INFO Synced                                  slot: 562294, block:    …  empty, epoch: 17571, finalized_epoch: 15614, finalized_root: 0xb380…b440, peers: 28, service: slot_notifier
Oct 21 15:19:09.850 INFO New block received                      hash: 0xde7e…fd67, slot: 562295
Oct 21 15:19:11.489 ERRO Fork choice failed                      location: block gossip, error: CanonicalHeadLockTimeout

Expected Behaviour

Return slot out of bounds

Steps to resolve

There's no validation about future slots, and this code is being hit:

https://github.com/sigp/lighthouse/blob/master/beacon_node/beacon_chain/src/beacon_chain.rs#L907-L917

I'm not sure exactly what the validation should be, so would appreciate some input. I would think it's just the queried for slot has to be less than or equal to the canonical head's slot.

[paulhauner]

Oh nice find! Let's restrict this endpoint to never accept a slot that is higher than current_slot + 1. The + 1 is to allow a little tolerance for clock skew.