Does anyone know the recommended timeout configuration for WFM schedule publishing when running on a Genesys Cloud BYOC Edge deployment in America/Chicago? We are currently experiencing intermittent 504 Gateway Timeout errors during our weekly schedule publish process, specifically when processing a high volume of approved agent shift swaps. The issue seems to correlate with the size of the shift swap batch; when we process fewer than 50 swaps, the publish completes successfully within the standard timeout window. However, as we approach 100+ concurrent shift swap validations, the API call to /v2/wfm/schedules/{scheduleId}/publish hangs and eventually times out. Our Architect flow is configured to poll the publish status, but the initial request never returns a 200 OK or a definitive failure code. We are using the latest WFM SDK version available in the Chicago region, and our Edge nodes are sized according to the standard BYOC guidelines for our agent count. The logs show that the Edge node receives the request but does not forward it to the core WFM service within the expected latency window. This is causing significant delays in our schedule adherence reporting and agent self-service availability updates. We have verified that the network connectivity between our Edge nodes and the Genesys Cloud core services is stable, with no packet loss or high latency observed. The issue appears to be related to the processing load on the Edge node during the validation phase of the shift swaps. We are looking for best practices on how to optimize the WFM schedule publish process for high-volume shift swap environments on BYOC Edge. Should we be batching the shift swaps differently, or is there a specific configuration setting on the Edge node that needs to be adjusted to handle this load? Any insights from other teams managing similar WFM workloads on BYOC Edge would be greatly appreciated.