AlinsRan commented on issue #2821: URL: https://github.com/apache/apisix-ingress-controller/issues/2821#issuecomment-5113365531
Thanks for the detailed reproduction. ### This is a constraint of the standalone model, not a bug in the sync path `PUT /apisix/admin/configs` replaces the whole configuration atomically, and the controller always pushes a full snapshot. There is no incremental path, so anything not in that snapshot isn't part of the configuration the controller declares. Out-of-band resources survive today only because ADC echoes back fields it doesn't recognize from the config it fetched. That's an implementation detail, not a contract — and it's the same path that carried a stale `secrets_conf_version` into the payload and produced your 400. So we won't be making out-of-band registration a supported setup. ### Unblocking it today Restart the ADC container (or the controller pod) — the cached snapshot is rebuilt from the data plane on the next sync and reconciliation resumes. The cache is an LRU with a 1h TTL (`ADC_APISIX_STANDALONE_CACHE_TTL_MS`), so it also recovers on its own eventually. ### What we will fix The control plane shouldn't be blocked indefinitely by external state. ADC already exposes `bypassCache` on its sync API, but the controller doesn't pass it, and ADC keeps its cached snapshot on a failed sync. Wiring that up turns the deadlock into one failed sync that self-heals — robustness, not support for out-of-band writes. ### `$secret://` support You're right that there's no way to declare a secrets manager through the controller today. `secrets` isn't in the resource model, and `secretRef` is a different mechanism (reads a Kubernetes Secret, injects the value). The real answer is bringing `secrets` into the control plane so it becomes part of the snapshot. That's a feature and needs its own design discussion — note that once the controller owns `secrets`, anything registered out of band gets removed on the next sync. Could you open a separate issue for it? -- 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]
