Summary
applyBackendSwitchRule in internal/haproxy/dataplane_client.go tries up to 4 different Dataplane API paths (nested PUT → nested POST → legacy PUT → legacy POST) to handle v2/v3 endpoint layout differences. However, intermediate errors are silently discarded, making it very difficult to debug API compatibility issues.
Current behavior
When the preferred nested PUT fails, the code falls through to nested POST, then legacy PUT, then legacy POST. Only the final error (if all 4 fail) is returned. Errors from the first 3 attempts are lost.
Proposed fix
Log intermediate errors at debug level so operators can trace which API paths were attempted and why they failed:
log.V(1).Info("nested PUT failed, trying nested POST", "error", err)
// ... try nested POST
log.V(1).Info("nested POST failed, trying legacy PUT", "error", err2)
// ... etcAlternatively, wrap all errors into the final error using errors.Join or fmt.Errorf so the full chain is available to callers.
Context
Summary
applyBackendSwitchRuleininternal/haproxy/dataplane_client.gotries up to 4 different Dataplane API paths (nested PUT → nested POST → legacy PUT → legacy POST) to handle v2/v3 endpoint layout differences. However, intermediate errors are silently discarded, making it very difficult to debug API compatibility issues.Current behavior
When the preferred nested PUT fails, the code falls through to nested POST, then legacy PUT, then legacy POST. Only the final error (if all 4 fail) is returned. Errors from the first 3 attempts are lost.
Proposed fix
Log intermediate errors at debug level so operators can trace which API paths were attempted and why they failed:
Alternatively, wrap all errors into the final error using
errors.Joinorfmt.Errorfso the full chain is available to callers.Context
internal/haproxy/dataplane_client.go:355-383