A C++ dynamic module stops getting response callbacks after any local reply on the stream, including ones it didn't send. So a module that sets a response header works on proxied traffic but silently does nothing on a direct_response route, or on an error Envoy generated itself.
local_reply_sent_ is set in two places. In sendLocalResponse() that's fine, the module sent the response. But envoy_dynamic_module_on_http_filter_local_reply() sets it too, and that fires for every local reply whatever the source. After that the response headers, body and trailers entry points all return early without calling into the module.
Repro is just a direct_response route: onRequestHeaders runs, onResponseHeaders never does. The same filter against the Rust and Go SDKs works on the same config, and neither of them has this flag.
Dropping the assignment in the local_reply handler looks like enough, unless the suppression there is deliberate. Happy to send a patch.
main @ 8ea3b35, same in v1.39.0.
A C++ dynamic module stops getting response callbacks after any local reply on the stream, including ones it didn't send. So a module that sets a response header works on proxied traffic but silently does nothing on a
direct_responseroute, or on an error Envoy generated itself.local_reply_sent_is set in two places. InsendLocalResponse()that's fine, the module sent the response. Butenvoy_dynamic_module_on_http_filter_local_reply()sets it too, and that fires for every local reply whatever the source. After that the response headers, body and trailers entry points all return early without calling into the module.Repro is just a
direct_responseroute:onRequestHeadersruns,onResponseHeadersnever does. The same filter against the Rust and Go SDKs works on the same config, and neither of them has this flag.Dropping the assignment in the local_reply handler looks like enough, unless the suppression there is deliberate. Happy to send a patch.
main @ 8ea3b35, same in v1.39.0.