Skip to content

Conversation

@yanjunxiang-google
Copy link
Contributor

@yanjunxiang-google yanjunxiang-google commented Jan 12, 2026

There is a problem that during CDS update, the drop_overload in Envoy memory is wiped out. If EDS update never arrives, the drop_overload enforcement is lost, and only start to function after next EDS update arrives.
This PR fixes this issue by moving the drop_overload parsing logic to a common function update() which will cover both EDS succeeds cases and EDS timeout cases.

@yanjunxiang-google
Copy link
Contributor Author

/assign @yurykats

Signed-off-by: Yanjun Xiang <[email protected]>
@yanjunxiang-google
Copy link
Contributor Author

/assign @yanavlasov

void EdsClusterImpl::update(
const envoy::config::endpoint::v3::ClusterLoadAssignment& cluster_load_assignment) {
// Drop overload configuration parsing.
THROW_IF_NOT_OK(parseDropOverloadConfig(cluster_load_assignment));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that since update() is void, it's not expected to be doing any error checking. Maybe just log that overload wasn't applied and move on?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed offline, we want to reject the bad configuration by throwing an exception. This follows the same logic as other EDS updates.

@yurykats
Copy link
Contributor

LGTM

@yanjunxiang-google
Copy link
Contributor Author

/assign @adisuissa

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.

4 participants