https://www.gooddata.ai/ logo
Join Slack
Powered by
Editing a dashboard and I regularly get this error...
# gooddata-cloud
r
Editing a dashboard and I regularly get this error today. First time I've seen this:
k
The error in your screenshot says: > "Dashboard save failed. Remove any unavailable visualizations, then try again, or contact your administrator." This is a known issue in GoodData Cloud. Here are the most likely causes and steps to resolve it: [Dashboard Save Failed] Most Likely Causes 1. Visualizations referencing non-existent or invalid identifiers If recent changes were made to your Logical Data Model (LDM) — such as renamed attributes, removed fields, or changed mappings — existing visualizations may reference identifiers that no longer exist. [Cannot Find Visualization] 2. LDM mapping issues If attributes used in visualizations are unmapped or incorrectly mapped in the LDM, the dashboard will fail to save. [LDM Mapping Issue] 3. Stale cache after LDM changes If LDM changes were made and reverted, the cache may still hold stale references. [LDM/Cache Issue] Recommended Steps 1. Check each visualization via the API to verify all identifiers are valid:GET /api/v1/entities/workspaces/{workspaceId}/visualizationObjects/{insightId}Confirm all attributes, labels, filters, and facts still exist in the LDM. 2. Check LDM mappings: Go to Data tab → Edit mode → locate the relevant dataset → click Details → check the Data mapping tab for any warnings or unmapped fields. 3. Clear/invalidate the cache in your data source settings after any LDM corrections. 4. Remove any unavailable visualizations from the dashboard (as the error message suggests), then try saving again. 5. Capture a Trace ID from browser DevTools (Network/Console tab) while reproducing the error — this is essential if you need to escalate to GoodData Support at support.gooddata.com. 👍 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.
j
Hi @Ryan Peters, could you please provide the traceID from the console related to the error so we can check our logs for the error? Also, were any changes made to the LDM or datasources before seeing this error?
r
How would I get the traceID?
no LDM changes as far as I'm aware.
j
Here's how you can find the traceID: 1. Open Developer Tools Press 
F12
(or 
Cmd + Option + I
on Mac) to open the browser's Developer Tools. 2. Go to the Network tab Click on the Network tab at the top of the Developer Tools panel. 3. Reproduce the issue Perform the action that causes the error — this will capture the network requests. 4. Find the failed request Look for a request highlighted in red, or filter by status (e.g. 4xx / 5xx errors). 5. Click the request & check the Response Headers Click on the relevant request, then open the Headers tab. Look for a response header called 
X-GDC-Trace-ID
— the value next to it is your traceID.
If you cannot find this, you can provide us with a link to the dashboard and provide us steps to recreate the issue. Then we can pull the traceID as well.
r
image.png
Nothing shows in the network tab.
I do see these now:
Copy code
{
  "title": "Not Found",
  "status": 404,
  "detail": "Result not found in result cache",
  "resultId": "da58a6d84afb464005cabf42955dc65116932561",
  "traceId": "9ea36621906334fe305f987bdb3ab4c0"
}
and
Copy code
792.af7d60a82d63f142a84c.js:2 Tiger backend threw an error: CanceledError: canceled
    at AbortSignal.r (792.af7d60a82d63f142a84c.js:2:660309)
    at c.invokeTask (4542.e02320000da4cec2e31f.js:2:592585)
    at a.runTask (4542.e02320000da4cec2e31f.js:2:587990)
    at h.invokeTask [as invoke] (4542.e02320000da4cec2e31f.js:2:593661)
    at b (4542.e02320000da4cec2e31f.js:2:606287)
    at _ (4542.e02320000da4cec2e31f.js:2:606590)
    at AbortSignal.x (4542.e02320000da4cec2e31f.js:2:606855)
    at t.refreshAbortController (2390.d4469eb4f8f03498fd6e.js:2:76189)
    at t.componentWillUnmount (2390.d4469eb4f8f03498fd6e.js:2:76057)
    at ii (3576.f7ab764d5c757842d515.js:2:93969)
    at mt.request (792.af7d60a82d63f142a84c.js:2:667675)
j
Hey Ryan, those errors make sense given what's going on. The 404 "Result not found in result cache" is basically the dashboard trying to load data for a visualization that's pointing to a deleted 
filterContext
— so the compute result never lands in cache properly, and then the frontend throws that 
CanceledError
when it tries to abort the broken request. The root cause is that a 
filterContext
object got deleted from the 
tenant-reporting-base-v3
workspace but two dashboards are still referencing it. The quickest fix: 1. Open the affected dashboard 2. Look for any filters that appear missing or broken in the filter bar 3. Remove them and save 4. Re-add the correct filters after If saving is blocked entirely through the UI, we'll need to patch it via API — basically GET the dashboard definition, strip out the bad 
filterContextRef
(
2a035c1c-8b06-4070-a53f-90bbe408208e
), and PUT it back. Let me know if you hit that and I can walk you through it.
r
Will check
so I had deleted the dashboard, re-created, and same error(s) occurred. So it'll be the viz itself?
j
it is either a broken filter on the dashboard itself or on one of the visualizations if it is applied there.
r
So how would I fix a broken viz?
j
the same way as a dashboard. look for the broken filter and remove it. Check each filter and see if the values are populating correctly
r
So - there's only a single filter, which is the date filter, set to our default of case_opened.
j
Could you please send me a direct link to the dashboard? You can send it to me in a DM if you prefer.
j
Hi Ryan, After looking into it more deeply, we've confirmed that what you're hitting is a known platform bug affecting multi-tab dashboards. On dashboards with multiple tabs, the dashboard layout definition can become duplicated internally — stored both at the root level and within the tab structure for backward compatibility. When the UI attempts to save, the resulting payload exceeds an internal size limit, which causes the save to fail with the error you're seeing. This also explains why re-creating the dashboard didn't help — the issue is tied to the tab structure itself, not the specific dashboard instance. Our engineering team is actively working on a fix and it has been escalated as high priority. We don't have a confirmed release date yet, but we'll update you as soon as it's deployed.
In the meantime, the dashboard can still be edited via the API as a workaround (if needed): 1. GET your dashboard definition via: 
/api/v1/entities/workspaces/{workspaceId}/analyticalDashboards/{dashboardId}
2. In the 
content
object, delete the top-level layout key — leave only the layout inside each tab under 
content.tabs[].layout
3. PUT the modified payload back to the same endpoint This should reduce the payload size below the limit and allows saving to succeed. Note: avoid saving the dashboard through the UI again until the fix is released, as it will re-introduce the duplicated layout on the next save attempt.
r
Thanks for this @Julius Kos
j
Hi Ryan, there has been some progress made on this so we would like to check to see if you are still experiencing this behavior
5 Views
Open in Slack
PreviousNext
Powered by