Skip to content

Ext proc client flow control - #12956

Open
kannanjgithub wants to merge 16 commits into
grpc:masterfrom
kannanjgithub:ext-proc-client-flow-control
Open

Ext proc client flow control#12956
kannanjgithub wants to merge 16 commits into
grpc:masterfrom
kannanjgithub:ext-proc-client-flow-control

Conversation

@kannanjgithub

Copy link
Copy Markdown
Contributor

No description provided.

…onformance

- Bypass sidecar readiness checks in `request(int)` when observability mode is false and response body mode is not `GRPC`.
- Ensure that when response headers, body, or trailers are skipped/disabled, they bypass request draining and stream directly downstream instead of being blocked.
- Fix sidecar mocks in tests to properly call `onCompleted()` when the request stream completes, preventing background stream leaks.
- Set appropriate processing modes in existing tests to match their flow control expectations under the updated logic.
…ffered use response processing mode GRPC so that buffered requests are actually sent to ext_proc instead of directly upstream in this test.
…send-mode-is-off' into ext-proc-client-flow-control

# Conflicts:
#	xds/src/test/java/io/grpc/xds/ExternalProcessorClientInterceptorTest.java
…RequestsAreNotBuffered to verify that when response_body_mode is NONE (and observability mode is disabled), request(int) calls are passed upstream immediately without being gated by sidecar readiness or buffered.
…ying the current message size, rather than after.
…port readiness

- Gated the transmission of `ClientWindowUpdate` messages by transport readiness.
  If the upstream client call is not ready (`isReady() == false`), the upstream window
  increment is kept at 0 to enforce backpressure.
- Modified `trySendAccumulatedWindowUpdates()` to avoid transmitting redundant,
  zero-increment window updates when transport readiness prevents replenishment. A
  `ClientWindowUpdate` is now sent only if at least one window increment is positive
  (`incrementUpstream > 0 || incrementDownstream > 0`).
- Updated `testClientWindowUpdateSentImmediatelyOnWindowExhaustion` to verify that no
  redundant window updates are sent while the transport is not ready, and that the
  accumulated `65536` increment is correctly flushed immediately upon calling `onReady()`.
- Fixed checkstyle violations (missing line separator) in the test code.
… client interceptor

- Queue mutated request body messages received from ext_proc in a new `pendingUpstreamBodyMessages` queue if the upstream transport is not ready (`isReady() == false`).
- Drain the queued request body messages and forward them to the transport when the transport becomes ready (triggered in `onReady()`).
- Defer request half-close if there are still body messages in the queue, executing the half-close once the queue is fully drained.
- Remove the `isReady()` check when merging or sending accumulated client window updates (`accumulatedWindowUpdateSidestreamToUpstream`), ensuring window updates are always propagated.
- Add a new unit test `testSidestreamToUpstreamFlowControl_QueuingAndDraining` in `ExternalProcessorClientInterceptorTest` to verify flow control queuing, transport transitions, and draining behavior.
…w-control

# Conflicts:
#	xds/src/test/java/io/grpc/xds/ExternalProcessorClientInterceptorTest.java
…w-control

# Conflicts:
#	xds/src/main/java/io/grpc/xds/ExternalProcessorClientInterceptor.java
#	xds/src/test/java/io/grpc/xds/ExternalProcessorClientInterceptorTest.java
Revert nit changes causing diffs.

Revert nit changes causing diffs.

Revert nit changes causing diffs.
@kannanjgithub
kannanjgithub force-pushed the ext-proc-client-flow-control branch from 399a16d to 98ec5be Compare July 30, 2026 10:13
@kannanjgithub
kannanjgithub requested a review from sauravzg July 30, 2026 11:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant