Prior to now, our earlier attempts to interact with BigQuery from GoodData Cloud have been easy peasy. As of today, we are getting the unhelpful combo of “Connection failed, try again later…” when in the Analyze interface. Data source connection tests come back as working. The only relevant mentions I’ve see as the more helpful messages are in pod logs in Kubernetes, but as a GoodData Cloud customer, we don’t have that access. So simple question here, if we want to find something useful about root cause of this message in GoodData Cloud, how do i get it?

Hi Kevin, you might check the browser dev console for more details, other than that I’m afraid there are not many options. If you are still seeing the error can you send me a traceID from dev console? I will check our logs to try to find the nature of the error.

Sure @Jan Kos, trace id: c50fc98aba7fedb8

Hi Kevin, thanks for the trace id. I can see there is an issue with the data filters in your workspace:

Cannot find workspace data filters for table='aws_billing_daily_866236652764_cost-and-usage-daily'

I would suggest making sure the filter definitions are still correct. More information here.

Hi @Moises Morales I don’t recall setting up workspaceDataFilters, but let me dump the organization json and see if I can see something, I’ll let you know!

Hello @Kevin Taylor. These 500 errors are unfortunately user faults not propagated well back to the user. It should respond you a 4xx about the data filters. But why it generates this error when no filters are defined, it is currently under investigation. Could you please share if it worked for you before and what actions were done in the meantime or if you just setup data source, model and you have not been able to query any data and you always see this error? Thank you.

Yes, they worked earlier, and they are showing up in places which feel very basic (for example, just going into the analyze view and making a simple table with just one row and one metric won’t return.). Another observed behavior was making a brand new workspace, attaching it to the same datasource, so it gets a new LDM, and even doing that and making a similar table in Analyze will also return a 500.

Thank you Kevin. Let me check few things on our side.

Something else to add I just thought to check. I also just went back to a workspace we built during trial pointed to a different bigquery data source, and it also has the same can’t display this insight error:

Could you please share tracing id for this one?

It’s the same symptoms as the issue we reported here, but on a different workspace and datasource. That might matter for potential root cause.

This seems like a different problem, but to confirm I would need tracing id from this computation. The error before which ended with the 500 is probably caused by a bug which is triggered when table id in GoodData Cloud and real table name are not the same. Could you please check it? it should be visible in the model. It has to have the same lower/upper case.

Okay. I’ll hold doing those in the event we can do it with screen share.

After investigation it was found out that it is caused by a bug which will be fixed next release - Feb 23. Problem is that we expect same table id (ldm reference) and table name (data source table) For BQ we translate "-" in table name to "_" in table id. Workaround is fix the physical model using:

/api/v1/layout/dataSources/datasourceID/physicalModel

I really banged my head against this, but no playing with the PDM API could give me a data source which worked. What I did try that did work was copying the table to a simpler tablename that did not use -’s. This did work. I’ll have an internal chat tomorrow about feasibility of changing this without exploding our data loaders. I would appreciate it if someone could help with updating the PDM via API., because I can’t see if I’m fixing one problem with the change and running into another error.

Unfortunately, as Martin mentioned, before the fix is delivered, in PDM table.id must equal to table name in the table.path (last element in the array). Additionally, the table.id may not include dash character(and many others) - it is a general limitation for GoodData IDs. I can offer the following simpler workaround solution: create a view on top of the affected table with the name not containing the dash character. Would it work for you?

🎉 New note created.