Can anyone explain why the analytics service is intermittently returning a 502 bad gateway error when querying conversation details for date spans exceeding 30 days? we are building a multi-tenant reporting dashboard via appfoundry and hitting this wall consistently when customers request historical data beyond the monthly threshold. the endpoint /api/v2/analytics/conversations/details/query works perfectly for 7 or 14 day windows, but once we push past that, the request hangs for roughly 45 seconds before failing with a cloudflare 502.
our implementation uses the standard oauth2 client credentials flow with the analytics:read scope. we have verified that the tokens are valid and active at the time of request. the payload includes filters for interaction type (voice) and a specific queue id. we are not hitting the documented rate limits, as we are spacing requests by 2 seconds. however, the 502 suggests the upstream service is timing out or crashing under the load of aggregating that much data.
we noticed that if we split the query into multiple 30-day chunks and aggregate the results client-side, the requests succeed. this is obviously inefficient and adds significant latency to our dashboard. is there a known limitation on the max date range for this specific endpoint that is not documented in the api reference? or is this a transient issue with the analytics cluster?
we are deploying this in the pacific region (us-west-2) and have observed the same behavior across multiple tenant accounts. the error response body is empty, which makes debugging difficult. we have checked the status page and there are no reported incidents for the analytics service.
any insights into the expected behavior for large date ranges would be appreciated. we are considering switching to the streaming endpoint /api/v2/analytics/conversations/details/stream, but that requires maintaining persistent connections and handling backpressure, which complicates our current architecture. is the streaming endpoint the recommended approach for historical data retrieval, or is there a workaround for the batch query endpoint?