Skip to content

fix: health check probes blocked indefinitely when EDS initialFetchTimeout is 0s - #46667

Open
yuehaii wants to merge 1 commit into
envoyproxy:mainfrom
yuehaii:eds-initialFetchTimeout
Open

fix: health check probes blocked indefinitely when EDS initialFetchTimeout is 0s#46667
yuehaii wants to merge 1 commit into
envoyproxy:mainfrom
yuehaii:eds-initialFetchTimeout

Conversation

@yuehaii

@yuehaii yuehaii commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Commit Message:
when a cluster is configured with EDS and initialFetchTimeout: 0s, the cluster stays in warming state indefinitely until EDS delivers its first response, no timeout fires to unblock it.

Additional Description:
added a bypass in ClusterImplBase::setHealthChecker(). when health_check_after_cluster_warming is enabled, health checks are still started immediately if both conditions hold:

  1. the EDS config source has initialFetchTimeout: 0s (hasZeroInitialFetchTimeout() == true)
  2. there are no pending SDS init targets (init_manager_.uninitializedCount() == 0)

Risk Level:
Low

Testing:
Will be added soon.

Release Notes:
fix health check probes being blocked indefinitely on EDS clusters configured with initialFetchTimeout: 0s. With health_check_after_cluster_warming enabled(default), health checks are no longer deferred when EDS warming has no timeout deadline.

Fixes #46666

…eck_after_cluster_warming is enabled

Signed-off-by: hai.yue <20416005+yuehaii@users.noreply.github.com>
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.

health check probes blocked indefinitely when EDS initialFetchTimeout is 0s

1 participant