Baoyuantop commented on code in PR #2732:
URL:
https://github.com/apache/apisix-ingress-controller/pull/2732#discussion_r2939660265
##########
internal/controller/ingress_controller.go:
##########
@@ -731,6 +736,26 @@ func (r *IngressReconciler) updateStatus(ctx
context.Context, tctx *provider.Tra
})
}
}
+ } else if svc.Spec.Type == corev1.ServiceTypeClusterIP {
Review Comment:
Current Ingress Reconcile Process: Reconcile() → updateStatus() → Write to
Ingress status.
The logic of the ClusterIP code path is:
1. Query all Ingresses that reference the ClusterIP service
2. Extract the hostname from their .Status.LoadBalancer.Ingress
3. Write the hostname to the status of the Ingress currently being reconciled
Issue: If the Ingress being reconciled also references that ClusterIP
service (via a service pointed to by `publishService`), then:
- Ingress A is reconciled → Query the list of Ingresses referencing that
service → The list may include Ingress A itself
- Ingress A’s status is updated → triggers a new reconcile → queries again →
potentially causing an infinite loop
Although the reflect.DeepEqual check (L770) short-circuits when the status
remains unchanged, this relies on a prerequisite: that the hostnames collected
from other Ingresses remain unchanged between two reconciles. If multiple
Ingresses are being reconciled concurrently, a race condition may lead to
repeated updates.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
