extproc: register filter and parse base and override config by eshitachandwani · Pull Request #9073 · grpc/grpc-go

eshitachandwani · 2026-04-17T08:29:34Z

This PR is part of implementing A93: xds-ext-proc

This PR adds the ext_proc filter and the builder that implements the builder interface. That includes parsing and validating the base and the override config. The registration of the filter is under the GRPC_EXPERIMENTAL_XDS_EXT_PROC_ON_CLIENT flag.

#ext-proc-a93

RELEASE NOTES: None

codecov · 2026-04-17T08:33:51Z

Codecov Report

❌ Patch coverage is 76.51007% with 35 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.09%. Comparing base (06fc26a) to head (9c30b51).
⚠️ Report is 29 commits behind head on master.

Files with missing lines	Patch %	Lines
internal/xds/httpfilter/extproc/ext_proc.go	72.22%	19 Missing and 6 partials ⚠️
internal/xds/httpfilter/extproc/config.go	68.00%	8 Missing ⚠️
internal/xds/httpfilter/extconfig.go	92.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #9073      +/-   ##
==========================================
+ Coverage   80.52%   83.09%   +2.56%     
==========================================
  Files         413      417       +4     
  Lines       33543    33648     +105     
==========================================
+ Hits        27012    27959     +947     
+ Misses       4316     4259      -57     
+ Partials     2215     1430     -785

Files with missing lines	Coverage Δ
internal/optional/optional.go	`100.00% <100.00%> (ø)`
internal/xds/httpfilter/extconfig.go	`92.00% <92.00%> (ø)`
internal/xds/httpfilter/extproc/config.go	`68.00% <68.00%> (ø)`
internal/xds/httpfilter/extproc/ext_proc.go	`72.22% <72.22%> (ø)`

... and 61 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

mbissa · 2026-04-17T11:15:41Z

/gemini review

gemini-code-assist

Code Review

This pull request implements the Envoy external processing (ext_proc) HTTP filter for xDS, including configuration parsing for base and override settings. The reviewer noted that the implementation incorrectly uses a non-existent GRPC body processing mode instead of STREAMED and lacks support for TypedStruct types in the configuration parser. As a result, the validation logic and unit tests require updates to correctly handle supported processing modes and additional configuration formats.

mbissa · 2026-04-20T08:47:53Z

LGTM, barring the udpa.type.v1.TypedStruct and xds.type.v3.TypedStruct support comment from gemini. Can go ahead if we get an answer on those.

eshitachandwani · 2026-04-21T03:29:56Z

LGTM, barring the udpa.type.v1.TypedStruct and xds.type.v3.TypedStruct support comment from gemini. Can go ahead if we get an answer on those.

It has been discussed that we only have to support udpa.type.v1.TypedStruct and xds.type.v3.TypedStruct for third-party filters and need not be supported for filters already in xDS

eshitachandwani · 2026-05-12T10:16:27Z

/gemini review

gemini-code-assist

Code Review

This pull request introduces a generic Option[T] type and implements the configuration parsing logic for the xDS external processing filter, including structures for base and override configurations. Critical feedback highlights potential runtime panics due to missing nil checks on protobuf message types and the ExtProcPerRoute override field. Other suggestions address misleading error prefixes in shared utilities, unnecessary whitespace, and various typos in comments and error messages.

easwars · 2026-05-12T20:19:06Z

+	// ChannelCredentials specifies the transport credentials to use to connect to
+	// the external server. Must not be nil.
+	ChannelCredentials json.RawMessage
+	// CallCredentials specifies the per-RPC credentials to use when making calls
+	// to the external server.
+	CallCredentials []json.RawMessage


These fields are still not comparable. We need it to be a string. Byte slices are not comparable. Please add a test to ensure that you can store this field in a map.

Changed to string. But ServerConfig as a whole is still not comparable and cannot be used as a key because :

metadata is a map which is not comparable

We do not want to compare the timeout and metadata as they are set per RPC , not per channel.
I think we should move these fields out of ServerConfig and into the InterceptorConfig. WDYT ?

Please clarify that the string value for ChannelCredentials and CallCredentials specifies their configuration as a JSON string.

I think we should move these fields out of ServerConfig and into the InterceptorConfig. WDYT ?
I don't think so, because we might have other users (who are not filters) that want those values.

Let's consider storing metadata as []HeaderValue where HeaderValue is defined as:

type HeaderValue struct { Key string Value string // is set when `Key` does not end with a `-bin` suffix RawValue string // Base64 encoded value of the header when `Key` ends with a `-bin` suffix }

Will this work?

Slices are also not directly comparable. We can have an Equal or EqualChannel method on the ServiceConfig and in that we can just compare the targetURI and the creds and leave out comparing the metadata. Then we can use the whole ServerConfig as the key. If we do this, we can also use bootstrap.ChannelCredentials and bootstrap.CallCredentials defined here , directly since they have an Equal method already defined. WDYT?

Where is the Equal method that you are talking about?

Oops, attatched the wrong type and file. I was talking about using this type

easwars · 2026-05-15T17:31:33Z

+	// ChannelCredentials specifies the transport credentials to use to connect to
+	// the external server. Must not be nil.
+	ChannelCredentials json.RawMessage
+	// CallCredentials specifies the per-RPC credentials to use when making calls
+	// to the external server.
+	CallCredentials []json.RawMessage


Please clarify that the string value for ChannelCredentials and CallCredentials specifies their configuration as a JSON string.

I think we should move these fields out of ServerConfig and into the InterceptorConfig. WDYT ?
I don't think so, because we might have other users (who are not filters) that want those values.

Let's consider storing metadata as []HeaderValue where HeaderValue is defined as:

type HeaderValue struct { Key string Value string // is set when `Key` does not end with a `-bin` suffix RawValue string // Base64 encoded value of the header when `Key` ends with a `-bin` suffix }

Will this work?

easwars · 2026-05-15T19:23:58Z

+}
+
+// resolveHeaderMode resolves the processing mode for headers based on the
+// protobuf enum value. If the mode is not set or set to Default, it returns the


Can we say ProcessingMode_DEFAULT in that case to be clear?

easwars · 2026-05-15T19:46:16Z

+		return modeSend
+	case v3procfilterpb.ProcessingMode_SKIP:
+		return modeSkip
+	default:


Also, it might be better here and down in resolveBodyMode to have a case for ProcessingMode_DEFAULT and not have a default case. That way, if a new enum value is added, we don't silently treat it like the default.

added a ProcessingMode_DEFAULT in the resolveHeaderMode but body mode does not have a ProcessingMode_DEFAULT and we need default statement because : As mentioned in the official GO documentation here , in point 6 , Switch is only terminating if it has a default case and all the cases including default has a return statement.

easwars · 2026-05-20T04:57:09Z

+	grpctest.RunSubTests(t, s{})
+}
+
+func testParseGRPCServiceConfig(grpcService *corepb.GrpcService) (xdsresource.GRPCServiceConfig, error) {


Can you please add a comment for this function, and mention that this is probably a temporary one until A102 is implemented.

easwars · 2026-05-20T05:06:57Z

+	// ChannelCredentials specifies the configuration for the transport
+	// credentials to use to connect to the external server, as a JSON string.
+	ChannelCredentials string
+	// CallCredentials specifies the configuration for the per-RPC credentials to
+	// use when making calls to the external server, as a JSON string.
+	CallCredentials string


If we are going to go with the approach where we are not going to bother to make this type be comparable, then, we should consider making the channel credentials be of type credentials.Bundle and the call credentials be of type credentials.PerRPCCredentials. (Note: see the xds/bootstrap package API for why we need a credentials.Bundle and not a credentials.TransportCredentials).

Then, as part of A102, when we parse the grpc_service proto into this struct, we can store a wrapped struct for the above fields, which embeds the credentials, but also stores the actual JSON configuration for the credentials.

And then, there needs to be an Equal method implemented here, that can actually compare the JSON configs of the credentials as part of the equality check.

What do you think?

We can do that , but from what I could understand, we agreed for this to be part of A102 implementation , i.e. if we are already going to have a functionality that will take in the ServiceConfig and give us the grpc channel , behind the scene it will have ad to have some sort of mapping for the string and the actual transportCredentials. So I was thinking that we can keep the channelCreds and call creds as strings , and we can take the values from here to create a channelKey in the filter (or wherever needed) and directly compare them. But we can have an Equal method incase anyone wants to compare the whole ServiceConfig.

But what you suggested also makes sense if we first get the whole serviceConfig and then we make a copy of it where metadata and timeout are nil values and we use that as a key and then we can directly use the Equal method defined for the whole struct.

Let me know what you think.

eshitachandwani added 2 commits April 17, 2026 13:44

add ext_proc parsing

11a461a

add env config

acce672

eshitachandwani added this to the 1.82 Release milestone Apr 17, 2026

eshitachandwani added the Type: Feature New features or improvements in behavior label Apr 17, 2026

Merge branch 'master' into parsing_proc

04b7720

formatting

2eac09b

eshitachandwani requested review from easwars and mbissa April 17, 2026 09:07

eshitachandwani assigned easwars and mbissa Apr 17, 2026

gemini-code-assist Bot reviewed Apr 17, 2026

View reviewed changes

check error in tes

4473a5d

eshitachandwani assigned eshitachandwani and unassigned easwars and mbissa Apr 20, 2026

add regex validation and proc per route

ac256fd

eshitachandwani assigned easwars and mbissa and unassigned eshitachandwani Apr 20, 2026

easwars reviewed Apr 21, 2026

View reviewed changes

easwars assigned eshitachandwani and unassigned easwars Apr 21, 2026

review comments

96536f2

eshitachandwani requested a review from easwars April 23, 2026 19:36

eshitachandwani assigned easwars and unassigned eshitachandwani Apr 23, 2026

eshitachandwani mentioned this pull request May 12, 2026

extproc: implement ClientFilter and ClientFilterBuilder interface #9086

Open

gemini-code-assist Bot reviewed May 12, 2026

View reviewed changes

eshitachandwani added 2 commits May 12, 2026 16:03

minor fixes

83df378

minor fixes

d222084

easwars reviewed May 12, 2026

View reviewed changes

easwars assigned eshitachandwani and unassigned easwars May 12, 2026

eshitachandwani added 2 commits May 13, 2026 20:31

address review comments

d922e76

fixes

f20b9ce

eshitachandwani requested a review from easwars May 13, 2026 18:32

eshitachandwani assigned easwars and unassigned eshitachandwani May 13, 2026

easwars reviewed May 15, 2026

View reviewed changes

easwars assigned eshitachandwani and unassigned easwars and mbissa May 15, 2026

eshitachandwani added 2 commits May 18, 2026 14:02

review comments

435b1e4

review comments

fb8fab2

eshitachandwani requested a review from easwars May 18, 2026 08:42

eshitachandwani assigned easwars and unassigned eshitachandwani May 18, 2026

easwars assigned eshitachandwani and unassigned easwars May 20, 2026

easwars reviewed May 20, 2026

View reviewed changes

add testgrpcparse string

9c30b51

eshitachandwani requested a review from easwars May 20, 2026 08:57

eshitachandwani assigned easwars and unassigned eshitachandwani May 20, 2026

Conversation

eshitachandwani commented Apr 17, 2026

Uh oh!

codecov Bot commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

mbissa commented Apr 17, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mbissa commented Apr 20, 2026

Uh oh!

eshitachandwani commented Apr 21, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

eshitachandwani commented May 12, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

codecov Bot commented Apr 17, 2026 •

edited

Loading