Counterintuitive warp error for Unsupported endpoint version #3404
Description
Description
When hitting the /eth/v2/validators/blocks/{slot} endpoint with an invalid randao_reveal (and verify_randao=true or empty) Lighthouse will return this error:
$ curl "http://localhost:5052/eth/v2/validator/blocks/1000000"
{"code":400,"message":"BAD_REQUEST: Unsupported endpoint version: v2","stacktraces":[]}
This makes zero sense, as the endpoint is cleared declared supporting v2 here:
lighthouse/beacon_node/http_api/src/lib.rs
Lines 1928 to 1935 in 2983235
Adding a panic to unsupported_endpoint_version to get a backtrace shows some funky warp stuff going on:
thread 'tokio-runtime-worker' panicked at 'unsupported_version_rejection: v2', beacon_node/http_api/src/version.rs:60:5
stack backtrace:
0: rust_begin_unwind
at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/panicking.rs:142:14
2: http_api::version::unsupported_version_rejection
3: <warp::filter::and_then::AndThenFuture<T,F> as core::future::future::Future>::poll
4: <warp::filter::and::AndFuture<T,U> as core::future::future::Future>::poll
5: <warp::filter::and::AndFuture<T,U> as core::future::future::Future>::poll
6: <warp::filter::and::AndFuture<T,U> as core::future::future::Future>::poll
7: <warp::filter::and::AndFuture<T,U> as core::future::future::Future>::poll
8: <warp::filter::and_then::AndThenFuture<T,F> as core::future::future::Future>::poll
9: <futures_util::future::try_future::into_future::IntoFuture<Fut> as core::future::future::Future>::poll
10: <warp::filter::or::EitherFuture<T,U> as core::future::future::Future>::poll
11: <warp::filter::or::EitherFuture<T,U> as core::future::future::Future>::poll
12: <F as futures_core::future::TryFuture>::try_poll
13: <warp::filter::or::EitherFuture<T,U> as core::future::future::Future>::poll
14: <warp::filter::and::AndFuture<T,U> as core::future::future::Future>::poll
15: <warp::filter::or::EitherFuture<T,U> as core::future::future::Future>::poll
16: <warp::filter::recover::RecoverFuture<T,F> as core::future::future::Future>::poll
17: <warp::filters::log::internal::WithLogFuture<FN,F> as core::future::future::Future>::poll
18: <warp::filters::cors::internal::WrappedFuture<F> as core::future::future::Future>::poll
19: scoped_tls::ScopedKey<T>::set
20: <warp::filter::service::FilteredFuture<F> as core::future::future::Future>::poll
21: hyper::proto::h1::dispatch::Dispatcher<D,Bs,I,T>::poll_catch
22: <hyper::server::conn::upgrades::UpgradeableConnection<I,S,E> as core::future::future::Future>::poll
23: <hyper::server::server::new_svc::NewSvcTask<I,N,S,E,W> as core::future::future::Future>::poll
24: tokio::runtime::task::core::CoreStage<T>::poll
25: tokio::runtime::task::harness::Harness<T,S>::poll
26: std::thread::local::LocalKey<T>::with
27: tokio::runtime::thread_pool::worker::Context::run_task
28: tokio::runtime::thread_pool::worker::Context::run
29: tokio::macros::scoped_tls::ScopedKey<T>::set
30: tokio::runtime::thread_pool::worker::run
31: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
32: tokio::runtime::task::harness::Harness<T,S>::poll
33: tokio::runtime::blocking::pool::Inner::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
i.e. it seems that warp is doing some counterintuitive backtracking through a few and_then/and/or until it hits the unsupported_version_endpoint for a different endpoint (one that is v1 only). This makes little sense to me, and would probably require someone to dig pretty deep into warp to understand why this happens. I think this is similar to another open issue (#3112) related to our apparent misuse of warp combinators.
Finally, if verify_randao=false is set or the randao reveal is valid then no error occurs:
$ curl "http://localhost:5052/eth/v2/validator/blocks/3574858?verify_randao=false"
{ .. }
Version
v2.5.0