AlinsRan commented on issue #2840:
URL:
https://github.com/apache/apisix-ingress-controller/issues/2840#issuecomment-5475454755
Traced this on master (`f1ad295`) and the mechanism looks different from the
description, so worth clarifying before anyone builds on it.
**Sync failures do reach the status.** `Provider.Update` doesn't push to the
data plane — `Client.UpdateConfig` only writes the local store:
```go
func (c *Client) UpdateConfig(ctx context.Context, args Task) error {
_, err := c.applyStoreChanges(args, false)
return err
}
```
The push happens in the background sync loop, and its failures come back
through `handleADCExecutionErrors` → `resolveADCExecutionErrors` →
`handleStatusUpdate`, which writes a condition onto
HTTPRoute/GRPCRoute/TCPRoute/UDPRoute (`internal/provider/apisix/status.go:111`
for HTTPRoute, merged into the matching parent). So moving the status write
after `Provider.Update` wouldn't capture sync failures — they aren't in that
call path.
**Translation failures are the real blind spot**, but the reachable set is
small. `TranslateHTTPRoute` has a single error path, `unknown path match type`,
and `HTTPPathMatch.Type` is a CRD enum, so the API server rejects that input
first. `TranslateGRPCRoute` has one that is reachable: `service and method
cannot both be empty for exact match type`. The CEL rule upstream is
`has(self.type) ? has(self.service) || has(self.method) : true`, so with `type`
unset both can be empty. Such a route never reaches the store, nothing can
attribute an error to it, and the status stays `Accepted=True`.
Worth separating out one more case: the reconciler's own pre-checks do reach
the status. A missing `PluginConfig` makes `processHTTPRoute` return an error
and sets `Accepted=False`. That one isn't invisible — the problem there is that
`isRouteAccepted` reads the parent conditions rather than that status, so the
route is still programmed and served without the filter. That's #2841, and it
doesn't actually depend on this issue.
Three things did turn up while tracing, none of them what this issue
describes:
- `handleStatusUpdate` writes `Accepted=True` unconditionally when a
resource leaves the failure set, and `MergeCondition` replaces by type with no
`ObservedGeneration` guard, so it can overwrite a genuine
`NoMatchingListenerHostname`.
- The async path uses `Accepted` to carry data-plane state, which collides
with the `PartiallyInvalid` requirement that `Accepted` be True.
- In standalone the failure event carries no resource information, so
`handleEmptyFailedStatuses` marks every object in the config as failed — one
bad route can flip the whole gateway.
Given that, does it make sense to close this one and track the GRPCRoute gap
separately, with those three as their own discussion about which condition owns
what?
--
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]
