A50: Exclude locally-initiated client cancellations from Call Counter (#12923)

[AgraVator]

Summary

Clarifies gRFC A50 (A50-xds-outlier-detection.md) to explicitly specify that locally-initiated client-side cancellations (hedging cancellations, application cancellation, and deadline exceeded) are excluded from the Outlier Detection Call Counter.

Key Clarifications

1. Picker: Updates the counter in the map entry on request completion.
2. Call Counter: Specifies that the active bucket tracks successes and failures while excluding locally-initiated client-side cancellations (hedging cancellations, application cancellation, and deadline exceeded etc).
3. Rationale:
   • Hedging & Application Cancellations: Align with Envoy's resetStream() behavior (silently resetting the stream without recording endpoint errors), preventing false-positive ejections during hedging.
   • Deadline Exceeded: Differs from Envoy (which counts timeouts as failures for outlier detection). In gRPC, client-side deadline expiration cannot be reliably distinguished from other client cancellations cross-language, and client timeouts cannot be definitively attributed to an endpoint failure rather than network or client-side delays.

Related Work

• gRPC-Java PR #12923: https://github.com/grpc/grpc-java/pull/12923/changes
• Envoy Outlier Detection: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/outlier

[kishorekasi]

A race or network delay can result in client trigger CANCELLED due to deadline before server responds with DEADLINE_EXCEEDED. This can result in outlier detector not counting it. Aren't both scenarios same and counted equally? Ref: #560

[AgraVator]

Hi,
Client timeouts can stem from client-side queuing or transit delays rather than endpoint unhealthiness which should not be counted as failures.
cc @ejona86

[kishorekasi]

Please let me know if my understanding is correct: once a physical attempt has been assigned to an endpoint, the client deadline can race with the server’s DEADLINE_EXCEEDED response. The same attempt may therefore be excluded as a client-side timeout or counted as a server response depending on which signal arrives first. Is the proposal intentionally excluding client/parent deadline expiry while counting a server-returned DEADLINE_EXCEEDED? We are hoping the API can expose enough information for a policy to optionally count deadline expiry for an active endpoint attempt, while still excluding explicit cancellations and non-winning retry or hedging attempts.