htuch

Legit failure https://dev.azure.com/cncf/envoy/_build/results?buildId=160405&view=logs&j=5b1da4ae-91c5-53b4-2dce-4cdfc8f90e84&t=f30788fd-b316-5c76-fa87-c77f9b4e50ec

Can probably just follow https://fmt.dev/latest/api.html#formatting-user-defined-types and provides a `format_as` with `fmt::underlying` for HeaderType in https://github.com/envoyproxy/envoy/blob/d15fee54dbebc8acc7781374d0189f402d87db8e/contrib/sip_proxy/filters/network/source/metadata.cc#L180.

Looks like legit failures in CI https://dev.azure.com/cncf/envoy/_build/results?buildId=162441&view=logs&j=767be981-567e-57d8-68c3-2140ede0a0bd&t=2181edf2-f610-59f2-c43a-04bb9d0bca00

Seems reasonable to go with a retry policy at the gRPC service level (e.g. using Google gRPC in-built, EnvoyGrpc specifying a retry policy). @stevenzzzz one thing to be aware of...

@nrshrivatsan agreed that this would be useful. Do you have plans to contribute here or should we mark this as "help wanted"?

I think some of them were added for tap2pcap tests https://github.com/envoyproxy/envoy/blob/b0e15260326d0d6175bc2271fb712f2f1efb029e/api/tools/tap2pcap_test.py. I don't think tshark / tcpdump are unusual for test environment for a network proxy.

@adisuissa

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/data_sharing_between_filters.html#filter-state-sharing provides the guidance on this. I think it's not a readable doc these days and could benefit from a table summary and more actionable guidance. Probably I would default...

Yeah, you're probably right @alhuan. Let's go with this as is.

@nezdolik looks like a legit CI failure from this PR.