Otto van der Schaaf

Hah, curious to hear what others think about this, but my 2p is that I like this. IMHO the extra complexity introduced by the templating is worth it, as this...

(for those who'd like hands on with the PoC @eric846 posted above: I had to `#include ` to get it to build.)

We have landed the failure predicates, which is handy in CI, and also a small python based framework for scripting simple tests and setting expectations to those. Possibly the gRPC...

Cross-linking the first step that landed for this: https://github.com/envoyproxy/nighthawk/pull/337

The cause *might* be related to the different resolution of system_clock by llvm and gcc, ms vs ns.

I don't think anyone tried this with our test server yet, so you might be in uncharted terrain. What happens when you take the test-server filter out of the equation...

I see. I'm not sure if the wasm extension is supposed to generate a 200/OK, this might be just the way it behaves / a shared bug with vanilla Envoy?...

If you would like to measure impact of (wasm) extensions in Envoy proxy, then the setup you propose above sounds good to me: ``` nighthawk_client proxy with (wasm) extensions nighthawk_test_server...

I was looking at https://github.com/envoyproxy/nighthawk/pull/492, another thought related to this topic So please hear me out ... currently on master StepController looks like: ```c++ virtual absl::StatusOr GetCurrentCommandLineOptions() const PURE; virtual...

FWIW This sounds awesome to me. New request sources may also bring in new dependencies, and the proposed approach here would be a great way to allow people to opt...