Thrift router impl does not check clusters exist while the config is created
https://github.com/envoyproxy/envoy/blob/main/source/extensions/filters/network/thrift_proxy/router/router_impl.cc#L21
Thrift uses the the rds in
https://github.com/envoyproxy/envoy/tree/main/source/common/rds

However http router impl does check these:

HTTP uses the rds in
https://github.com/envoyproxy/envoy/tree/main/source/common/router

The paths between thrift and http are very subtle and all the class name and template are very similar (but the implantation is totally different), which is another topic.

We do have a check while the traffic is thru the unknown cluster, but that's too late.
https://github.com/envoyproxy/envoy/blob/main/source/extensions/filters/network/thrift_proxy/router/router.h#L448

--

To achieve this, we need to let RouteEntryImplBase knows the ClusterManager which is from the FactoryContext

The fundamental change is to let the ConfigTrait provide the information to config

Consider the diff is only two weeks old at the moment and thrift is the only non-test client.
e727e1f

My proposal is to provide context while create the config, which is what mostly all factories do.
i.e.,

ConfigConstSharedPtr createConfig(const Protobuf::Message& rc,  Server::Configuration::ServerFactoryContext& context) ;

in

so the static provider and the config receiver (for rds) can provide the context by trait,
https://github.com/envoyproxy/envoy/blob/main/source/common/rds/static_route_config_provider_impl.cc#L14
https://github.com/envoyproxy/envoy/blob/main/source/common/rds/route_config_update_receiver_impl.cc#L18

==>
so we can let thrift RouteMatcher know the context
https://github.com/envoyproxy/envoy/blob/main/source/extensions/filters/network/thrift_proxy/router/config.h#L31
who generates those RouteEntryImpl
https://github.com/envoyproxy/envoy/blob/main/source/extensions/filters/network/thrift_proxy/router/router_impl.cc#L175

and eventually we can check if the cluster is known or not.

Does it make sense?

cc @htuch @rgs1 @mattklein123 @tkovacs-2