Running Genesys Cloud Edge v23.11 on AWS EKS. The BYOC deployment handles about 45k concurrent sessions. A custom Python pipeline pulls historical interaction data for the quarterly forecast model. It’s hitting /api/v2/analytics/interactions/summary with a 180-day window. Works perfectly in the standard SaaS environment. On the Edge cluster, the request drops a 422 Unprocessable Entity response. The payload returns {“code”: “invalid_request”, “message”: “Query window exceeds shard retention policy”, “errors”: [“max_interval_days: 60”]}.
Checked the analytics-service logs in the genesys-edge namespace. The pod throttles queries past the 60-day mark. Retention policies in the BYOC config only mention 90 days for compliance. The shard controller seems hardcoded to 60 anyway. Tried adjusting the max_query_window in the values.yaml override before the Helm install. Nothing changed. The Kubernetes deployment still enforces the limit.
Forecasting model relies on 180 days of historical volume to calculate the seasonal adjustment factor. Multi-skill queue distribution throws off completely when the dataset gets truncated. Erlang C calculations start predicting 30% more agents than necessary. Ran a quick test with the Genesys REST API SDK v3.1.2. Same error. Switched to raw curl calls through the Edge ingress. Still hitting the 422.
Anyone working with BYOC clusters see this shard retention cap? The WFM team can’t run the regression analysis without the full historical window. Chaining three 60-day requests is doing jack all for the daily volume normalization. The overlap creates a janky spike in the regression output. Edge version 23.11.2 doesn’t have a documented override for the analytics shard window.
kubectl logs -n genesys-edge analytics-service-7d9f8b6c4-x2k9p | grep “max_interval_days” shows the controller rejecting anything over 60. The values.yaml parameter analytics.shard.maxQueryDays exists in the schema but gets ignored during the upgrade job.