access_log(grpc): pass command parsers to custom tags (fix DNS filter validation)#43457
Merged
yanavlasov merged 9 commits intoFeb 14, 2026
Conversation
|
Hi @garimauttam, welcome and thank you for your contribution. We will try to review your Pull Request as quickly as possible. In the meantime, please take a look at the contribution guidelines if you have not done so already. |
Signed-off-by: garima-uttam <garimauttam@ibm.com>
Signed-off-by: garima-uttam <garimauttam@ibm.com>
816f25d to
b80167e
Compare
Signed-off-by: garima-uttam <garimauttam@ibm.com>
yanavlasov
approved these changes
Feb 14, 2026
Contributor
|
@yanavlasov i had #42915 already open with the same changes + the requested integration tests and was waiting on review FYI |
nickshokri
pushed a commit
to nickshokri/envoy
that referenced
this pull request
Mar 17, 2026
… validation) (envoyproxy#43457) Fixes envoyproxy#43396 ## What this PR does When DNS filter access logs use gRPC logger `custom_tags` with formatter-style values, validation can fail because extension command parsers are not propagated into gRPC custom tag creation. This PR threads `command_parsers` through the gRPC access log path so custom tag formatter values can resolve extension-specific commands (including DNS filter commands). ## Changes - Plumb `command_parsers` from gRPC access log config factories (`http_config`/`tcp_config`) into gRPC access log impls. - Update `CommonPropertiesConfig` to accept command parsers. - Pass command parsers to `Tracing::CustomTagUtility::createCustomTag(...)`. - Add a regression test in `tcp_config_test` to verify custom tag formatter values respect injected command parsers. ## Why this fixes the issue The failure came from building formatter-based custom tags without the extension parser set. After this change, custom tag parsing uses the same parser chain provided by the access log call site, so DNS-specific formatter commands are recognized correctly. ## Testing - `bazel test //test/extensions/access_loggers/grpc:tcp_config_test //test/extensions/access_loggers/grpc:http_config_test` ## Risk Low. The change is scoped to parser propagation for gRPC custom tag construction and includes targeted regression coverage. --------- Signed-off-by: garima-uttam <garimauttam@ibm.com> Signed-off-by: nick <nickshokri@google.com>
nickshokri
pushed a commit
to nickshokri/envoy
that referenced
this pull request
Mar 17, 2026
… validation) (envoyproxy#43457) Fixes envoyproxy#43396 ## What this PR does When DNS filter access logs use gRPC logger `custom_tags` with formatter-style values, validation can fail because extension command parsers are not propagated into gRPC custom tag creation. This PR threads `command_parsers` through the gRPC access log path so custom tag formatter values can resolve extension-specific commands (including DNS filter commands). ## Changes - Plumb `command_parsers` from gRPC access log config factories (`http_config`/`tcp_config`) into gRPC access log impls. - Update `CommonPropertiesConfig` to accept command parsers. - Pass command parsers to `Tracing::CustomTagUtility::createCustomTag(...)`. - Add a regression test in `tcp_config_test` to verify custom tag formatter values respect injected command parsers. ## Why this fixes the issue The failure came from building formatter-based custom tags without the extension parser set. After this change, custom tag parsing uses the same parser chain provided by the access log call site, so DNS-specific formatter commands are recognized correctly. ## Testing - `bazel test //test/extensions/access_loggers/grpc:tcp_config_test //test/extensions/access_loggers/grpc:http_config_test` ## Risk Low. The change is scoped to parser propagation for gRPC custom tag construction and includes targeted regression coverage. --------- Signed-off-by: garima-uttam <garimauttam@ibm.com> Signed-off-by: nick <nickshokri@google.com>
fishcakez
pushed a commit
to fishcakez/envoy
that referenced
this pull request
Mar 25, 2026
… validation) (envoyproxy#43457) Fixes envoyproxy#43396 ## What this PR does When DNS filter access logs use gRPC logger `custom_tags` with formatter-style values, validation can fail because extension command parsers are not propagated into gRPC custom tag creation. This PR threads `command_parsers` through the gRPC access log path so custom tag formatter values can resolve extension-specific commands (including DNS filter commands). ## Changes - Plumb `command_parsers` from gRPC access log config factories (`http_config`/`tcp_config`) into gRPC access log impls. - Update `CommonPropertiesConfig` to accept command parsers. - Pass command parsers to `Tracing::CustomTagUtility::createCustomTag(...)`. - Add a regression test in `tcp_config_test` to verify custom tag formatter values respect injected command parsers. ## Why this fixes the issue The failure came from building formatter-based custom tags without the extension parser set. After this change, custom tag parsing uses the same parser chain provided by the access log call site, so DNS-specific formatter commands are recognized correctly. ## Testing - `bazel test //test/extensions/access_loggers/grpc:tcp_config_test //test/extensions/access_loggers/grpc:http_config_test` ## Risk Low. The change is scoped to parser propagation for gRPC custom tag construction and includes targeted regression coverage. --------- Signed-off-by: garima-uttam <garimauttam@ibm.com>
krinkinmu
pushed a commit
to grnmeira/envoy
that referenced
this pull request
Apr 20, 2026
… validation) (envoyproxy#43457) Fixes envoyproxy#43396 ## What this PR does When DNS filter access logs use gRPC logger `custom_tags` with formatter-style values, validation can fail because extension command parsers are not propagated into gRPC custom tag creation. This PR threads `command_parsers` through the gRPC access log path so custom tag formatter values can resolve extension-specific commands (including DNS filter commands). ## Changes - Plumb `command_parsers` from gRPC access log config factories (`http_config`/`tcp_config`) into gRPC access log impls. - Update `CommonPropertiesConfig` to accept command parsers. - Pass command parsers to `Tracing::CustomTagUtility::createCustomTag(...)`. - Add a regression test in `tcp_config_test` to verify custom tag formatter values respect injected command parsers. ## Why this fixes the issue The failure came from building formatter-based custom tags without the extension parser set. After this change, custom tag parsing uses the same parser chain provided by the access log call site, so DNS-specific formatter commands are recognized correctly. ## Testing - `bazel test //test/extensions/access_loggers/grpc:tcp_config_test //test/extensions/access_loggers/grpc:http_config_test` ## Risk Low. The change is scoped to parser propagation for gRPC custom tag construction and includes targeted regression coverage. --------- Signed-off-by: garima-uttam <garimauttam@ibm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #43396
What this PR does
When DNS filter access logs use gRPC logger
custom_tagswith formatter-style values, validation can fail because extension command parsers are not propagated into gRPC custom tag creation.This PR threads
command_parsersthrough the gRPC access log path so custom tag formatter values can resolve extension-specific commands (including DNS filter commands).Changes
command_parsersfrom gRPC access log config factories (http_config/tcp_config) into gRPC access log impls.CommonPropertiesConfigto accept command parsers.Tracing::CustomTagUtility::createCustomTag(...).tcp_config_testto verify custom tag formatter values respect injected command parsers.Why this fixes the issue
The failure came from building formatter-based custom tags without the extension parser set. After this change, custom tag parsing uses the same parser chain provided by the access log call site, so DNS-specific formatter commands are recognized correctly.
Testing
bazel test //test/extensions/access_loggers/grpc:tcp_config_test //test/extensions/access_loggers/grpc:http_config_testRisk
Low. The change is scoped to parser propagation for gRPC custom tag construction and includes targeted regression coverage.