Hello! We’re hitting a 504 Gateway Timeout every time we call PUT on the layout API to upload our LDM to a cloned workspace (

/api/v1/layout/workspaces/{workspaceId}/logicalModel

). Response body says "Upstream service socket timeout". Happening on every run (we’ve retried a bunch). Same LDM that worked before when we cloned to another workspace, and we haven’t changed it. Our client is set to a 300s timeout, so we’re pretty sure the limit is on the gateway/upstream side. Can you check whether the gateway or upstream timeout for this endpoint can be increased (or if there’s something we should do on our side)? We’re blocked on finishing the workspace clone until this is resolved.

You’re right that this is almost certainly a platform-side timeout, not your client. From the docs, GoodData Cloud has a 180‑second limit for reading a response; if the server does not transmit anything within this time, the connection is closed. [API limits] In addition, there is a gateway layer (nginx) in front of the services, and when internal processing exceeds its limits you can see 504 “Gateway Time-out” / “Upstream service socket timeout” errors, as in similar cases with large organization/layout calls. [API limits; Org layout timeout] From the available information: • The timeout values for this endpoint are not configurable by customers; the docs only say that limits “can be changed after considering the individual use case” in a dedicated cluster. [API limits] • Similar long‑running layout/organization calls have hit internal processing limits and resulted in 500/504 errors until GoodData adjusted limits or recommended alternative APIs. [Org layout timeout] The knowledge sources do not describe any way for you to raise this timeout yourself or tune it per request, and they do not document a smaller per‑endpoint timeout for

PUT /api/v1/layout/workspaces/{workspaceId}/logicalModel

beyond the general 180‑second read limit. Given that: 1. There is no documented client‑side setting that would override the GoodData gateway/upstream timeout for this endpoint. 2. The same LDM worked previously in another workspace, so the payload itself is likely valid. 3. Similar “too big / too slow layout” situations have required GoodData support to adjust internal limits or suggest a different approach. [Org layout timeout] The only concrete, supported path from the docs is: • Open a support ticket (or use your GoodData support channel) with: ◦ The exact endpoint and method (

PUT /api/v1/layout/workspaces/{workspaceId}/logicalModel

) ◦ Organization and workspace IDs ◦ Recent trace IDs from failing calls ◦ Confirmation that the same LDM works in another workspace • Ask whether internal/gateway timeouts or processing limits for this operation can be adjusted for your organization or whether there is a recommended workaround (for example, splitting the layout, or using a different declarative endpoint). The docs explicitly say limits in a dedicated cluster can be changed after considering the use case. [API limits] I’m sorry I can’t give you a direct knob to turn here—the knowledge sources do not document any user‑configurable timeout for this API, so resolving this will require GoodData support to inspect your trace IDs and potentially adjust internal limits. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

Hello Nick, I see our AI assistant provided an accurate response, please let us know if you would like further assistance.

Hi Yvonne, I was able to get our clone to succeed by trying again a few minutes later. Thank you