xds/resolver: Optimize Interceptor Chain Construction #8641
Conversation
…tor, not for every RPC
easwars
added
Area: xDS
|
@eshitachandwani : FYI this might conflict with your resolver changes for A74. And since you have been looking at the resolver code for sometime now, it would be a good PR to review. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #8641 +/- ##
==========================================
- Coverage 79.45% 79.13% -0.32%
==========================================
Files 415 415
Lines 41339 41425 +86
==========================================
- Hits 32844 32782 -62
- Misses 6621 6713 +92
- Partials 1874 1930 +56
🚀 New features to boost your workflow:
|
|
@arjan-bal could you review this change, please? |
| // The filter config override maps contain overrides from the route, cluster, | ||
| // and virtual host respectively. The cluster override has the highest priority, | ||
| // followed by the route override, and finally the virtual host override. | ||
| func newInterceptor(filters []xdsresource.HTTPFilter, cluster, route, virtualHost map[string]httpfilter.FilterConfig) (iresolver.ClientInterceptor, error) { |
There was a problem hiding this comment.
nit: What do you think about adding an override suffix to cluster, route, and virtualHost? I find it can help with readability, but no worries if you prefer the current naming.
| cs := r.newConfigSelector() | ||
| cs, err := r.newConfigSelector() | ||
| if err != nil { | ||
| r.onResourceError(fmt.Errorf("xds: failed to create config selector: %v", err)) |
There was a problem hiding this comment.
Should the function return early after calling onResourceError? I'm not sure what happens when a nil config selector is passed to sendNewServiceConfig.
There was a problem hiding this comment.
I think we should return early since onResourceError will call sendNewServiceConfig with an erroring config selector, so we should not call sendNewServiceConfig again with a nil config selector (which will set a default config selector in client conn)
| // Should not happen if it passed xdsClient validation. | ||
| panic(fmt.Sprintf("filter %q does not support use in client", filter.Name)) |
There was a problem hiding this comment.
What do you think about continuing to return an error here? The method signature already allows for it, so callers presumably have error handling in place. Panicking to crash the process feels like a worse alternative, especially if this is a recoverable error.
| fb.logger.Logf("BuildClientInterceptor called with config: %+v, override: %+v", config, override) | ||
|
|
||
| if config == nil { | ||
| panic("unexpected missing config") |
There was a problem hiding this comment.
In my opinion printing an error to fail the test may be preferred to panicking from a spawned goroutine. The situation seems similar to the style guide recommendation about only calling t.Fatalf from the main test function.
| // by the backend, allowing tests to assert that the correct filter | ||
| // configuration was applied for each RPC. | ||
| type testHTTPFilterWithRPCMetadata struct { | ||
| logger logger |
There was a problem hiding this comment.
nit: Is there a benefit of using a logger interface here? If not, I think it's simpler to directory store a testing.T here .
|
|
||
| func (*testHTTPFilterWithRPCMetadata) IsTerminal() bool { return false } | ||
|
|
||
| var _ httpfilter.ClientInterceptorBuilder = &testHTTPFilterWithRPCMetadata{} |
There was a problem hiding this comment.
nit: I think we should add a comment here stating that ClientInterceptorBuilder is an optional interface for Filters to implement so this compile time check ensures the test filter implements it. In my opinion this would help readers.
| } | ||
| var errStr string | ||
| if newStreamErr != nil { | ||
| errStr = newStreamErr.Error() |
There was a problem hiding this comment.
I see that we're converting a string to an error, assigning it to testFilterCfg.newStreamErr and converting it back to a string here. Can the error string be stored in testFilterCfg.newStreamErr to avoid these conversions?
| } | ||
|
|
||
| func (cs *clientStream) Context() context.Context { | ||
| return cs.ctx |
There was a problem hiding this comment.
Do we need to store a context here? Can we return cs.ClientStream.Context() instead?
| if internal.NewXDSResolverWithConfigForTesting == nil { | ||
| t.Fatalf("internal.NewXDSResolverWithConfigForTesting is nil") | ||
| } |
There was a problem hiding this comment.
nit: We can avoid this check and let the code panic if we don't expect to fail in most cases.
There was a problem hiding this comment.
There is a bunch of commented code here that probably needs to be removed. Can you please take a look?
4 participants
Existing behavior:
New behavior:
Other changes:
RELEASE NOTES: NONE