Hi team, I'm having an issue with one of my dashbo...
# gooddata-cloud
t
Hi team, I'm having an issue with one of my dashboards that causes the page to crash. Unfortunately, it doesn't return any trace ID or other error message to the front end.
✅ 1
The YAML files for the dashboard were generated in one workspace, cloned down using GoodData CLI, and then deployed out to a new workspace. Once deployed, the visualizations and dashboard no longer work
m
Hi Tim, I have seen this error before, and it is usually caused by an object being improperly defined. This is likelier to happen when building the workspace via the APIs or Python SDK, for example: https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1740723524361399
Are you able to revert the changes? If not, could you provide more details as to the changes introduced before the issue happened?
t
When I clone the visualizations down, they are using a date filter with a granularity of 'WEEK_US'. When I try to re-deploy the files, I get the following error:
Copy code
26|    date_week_us:
    27|      type: date_filter
    28|      granularity: WEEK_US
    29|      from: 0
    30|      to: 0
       Value is not accepted. Valid values: "MINUTE", "HOUR", "DAY", "WEEK", "MONTH", "QUARTER", "YEAR", "MINUTE_OF_HOUR", "HOUR_OF_DAY", "DAY_OF_WEEK", "DAY_OF_MONTH", "DAY_OF_YEAR", "WEEK_OF_YEAR", "MONTH_OF_YEAR", "QUARTER_OF_YEAR".
If I change the WEEK_US to 'WEEK', it passes the validation successfully but doesn't work once deployed. A lot of the visualizations use a comparison (this week vs last week).
This is the filter from the UI view
m
Could you please send me a direct link to the workspace? I would like to take a closer look. TIA.
✅ 1
Hello Tim, please allow me to provide an update here to let you know that as discussed privately, the dashboard got broken by the incorrect date dimension set by the CLI. It can be fixed by modifying the dashboard object via the API to revert the dimension, but since the root cause was the CLI not recognizing WEEK_US, I reported this internally and our developers fixed it in v0.12. Could you please update the tool and confirm that the issue is fixed?
g
Hey Moises, thank you for the update! I changed the version to 0.12.0, replaced all
date_week_us
with
date_week
and tried deploying again, but view is still crashing on GD.
m
Hi Gabriela, please, can you try by changing only
WEEK_US
to
WEEK
, but keeping
date_week_us
.
g
Hey Mauricio, thank you. I tried deploying with these values but I get a blank page. Console shows these errors:
I'm running gd deploy with GoodData Analytics v0.12.0
No errors when running the command
m
It would be good to know the new workspace you are working with, I have checked the endpoint
/api/v1/layout/workspaces
and I don't see
6679e684-69d6-421e-ac84-bd648089342a
anymore (the original workspace mentioned in this thread). Please send a link to our private chat, although I believe the issue here is that the filter context is still using the wrong granularity given that the dev console still mentions the same error as before.
Just one more thing, you do not need to change anything from the workspace, as long as you are using the latest version of the CLI tool, the date granularity
WEEK
will be recognized. You can make sure about it, by validating the workspace with
Copy code
gd validate
g
Thanks. I ran
gd validate
and I get success
m
I have checked the workspace definition and found that you are using the granularity
GDC.time.week
instead of
GDC.time.week_us
, you will need to change all the instances were the wrong granularity is used to fix the issue provided that this was the only changed introduced. You can do so by doing a GET request to the following endpoint:
/api/v1/layout/workspaces/c4e7886f-ef90-4cd3-83d3-87a7ebcbf09c
Find all instances were
GDC.time.week
is used and replaced them for
GDC.time.week_us
. Use the modified layout as a body for the PUT request to the same endpoint and set the correct content-type as exemplified in the Apiary: https://www.gooddata.com/docs/cloud/api-and-sdk/api/api_reference_all/#operation/updateEntity@Workspaces Once the issue is solved, you will be able to clone the workspace locally via CLI and deploy it with this granularity without any issues.
g
Hi Moises, sorry about the delay, it was a holiday yesterday. I did like you said and now I can see the page! Thank you so much for your help
🙌 1
m
Hi Gabriela, I am glad to hear this is now working 🙂
Thank you for the update.