Problem
API7 Ingress Controller 2.1.0 defaults the api7ee provider to sync_period: 0s. In api7eeProvider.Start, startup synchronization runs, but the method then returns when SyncPeriod < 1 instead of entering the event loop.
Consequently, a zero period disables more than the periodic ticker:
syncCh notifications are no longer consumed. For example, GatewayProxy configuration updates can update the cache and call syncNotify without applying the change to the gateway.- retry notifications are no longer consumed.
- startup and delayed-startup synchronization failures do not reliably enter the retry path.
Expected behavior
sync_period: 0s should disable only periodic full synchronization. Explicit synchronization events, retries, and cancellation handling should remain active.
Additional lifecycle risk
The delayed startup synchronization currently uses time.AfterFunc, so it can run concurrently with the main synchronization loop or after Start returns. Synchronization, status handling, and retrier state changes should remain serialized in one loop.
Reference implementation
PR #457 contains a tested candidate fix and regression coverage, but is being closed so the implementation can be owned and reviewed by Ingress Controller engineering.
Validation completed on that patch:
go test -v ./internal/provider/api7eego test ./internal/provider/...go test -race ./internal/provider/api7ee
Problem
API7 Ingress Controller 2.1.0 defaults the
api7eeprovider tosync_period: 0s. Inapi7eeProvider.Start, startup synchronization runs, but the method then returns whenSyncPeriod < 1instead of entering the event loop.Consequently, a zero period disables more than the periodic ticker:
syncChnotifications are no longer consumed. For example,GatewayProxyconfiguration updates can update the cache and callsyncNotifywithout applying the change to the gateway.Expected behavior
sync_period: 0sshould disable only periodic full synchronization. Explicit synchronization events, retries, and cancellation handling should remain active.Additional lifecycle risk
The delayed startup synchronization currently uses
time.AfterFunc, so it can run concurrently with the main synchronization loop or afterStartreturns. Synchronization, status handling, and retrier state changes should remain serialized in one loop.Reference implementation
PR #457 contains a tested candidate fix and regression coverage, but is being closed so the implementation can be owned and reviewed by Ingress Controller engineering.
Validation completed on that patch:
go test -v ./internal/provider/api7eego test ./internal/provider/...go test -race ./internal/provider/api7ee