Hey all, I've got an interesting issue where I'm getting an error about an ambigious context for count:

{
  "title": "Bad Request",
  "status": 400,
  "detail": "Ambiguous context for count, attribute='attribute/DIM_VISIT.DIM_VISIT_ID/LMN_Single_Parent'",
  "traceId": "8192934800264469c15083aa21090c1f"
}

Error TraceID: 8192934800264469c15083aa21090c1f

New message text here

I do with this would give better diagnostics though, which specific usage or which metric, etc is invalid for instance.

Hi Steve, our AI assistant is still is still in it’s infancy and we working on improvements, so we really we appreciate the feedback. Regarding the model validation - Would you please be so kind as to provide more detials and clarify is you need further assistance with that or that again is feedback? Thank you!

I was able to fix my issue luckily by using the advice of the AI assistant. So that was good. But two things • we validate our analytical model using the api ◦ I'm looking at my dashboard I get an error telling me "you have an ambiguous column reference" causing my insight to be incorrect ◦ why do I have a "valid" analytical model? ▪︎ and I can guarantee you that our model used to be correct 2-3 months ago because this was not broken then but is now • feels like something has changed there • when seeing an error in the UI, great to say: "you have an issue with an insight", the details in the output are no really helpful other than they give you a hint. ◦ I was able to read the details and see what it meant, however because I had the same "problem" in 5-6 metrics I had to keep digging to find it. ◦ Could have used the API to look at the full model, but still not super helpful that way.

I’m not aware of any changes regarding the model validation. But please let me double-check this. And thank you again for the feedback regarding point 2 - I agree that the error in the UI could provide more details on the cause of the issue.

The error is "accurate", just not precise. Great to know its ambiguous, but where is it ambiguous • which metric? • which attribute or column in the insight.... • etc.

Hi Steve, if I may add a small bit here — an ambiguous path doesn’t necessarily mean the model is invalid. It just means GoodData couldn’t decide which path to use for that COUNT. The model can still be valid, but ambiguity can cause errors like the one you saw, sometimes slower queries, or even unexpected results. Since you’ve already fixed it, there's nothing specific we can trouble-shoot now. As my colleague mention we are not aware of any changes in this context but surely we will submit product feedback that the error message should point to the exact metric or insight, which would make this much easier to find next time. Totally agreed there. Thank you for sharing your experience with the product.

🎉 New note created.

How can it be valid, if when I use the insight it throws an error or says there is an issue.

Hi Steve, yes that's a valid point indeed. My bad I understood that you've only saw some warnings not that the Insights were actually inaccessible. The product feedback regarding the error clarity has been already submitted and it's definitely a legit one. We will also consult this further with our Technical team to see their opinion on this and will let you know in case of further update.

thank you, let me know if you need information. I was on the product quarterly demo and saw the new run/test sql in metric authoring, and that would be super beneficial here.

Hello Steve! This is Daniela with the Technical Team. I’m currently checking the thread and I’ll let you know soon about the model validation.

Thank you for the summary let me try and summarize this to make sure I understand fully what happened here. 1. There was a change to the validation on execution that catches cases where results are non-deterministic. a. meaning before that change there would have not been an error shown, but the results were potentially incorrect 2. Our organization checks both LDM and Analytical Models for validation. a. The analytical model validation does not include the enhanced validation b. Which is why, even when the validation was correct, we could have missed the issue. 3. There is a run/sql script update coming (saw on latest product roadmap) that would help us diagnose these while authoring metrics a. 100% cannot wait for this feature. For 2b -> Feel this doesn't make sense, if you have added more validation, why are we not able to use that for Analytical Model validation? Feels like the idea valid or not should not be on the end user to see because thats what would have happened if the feature we were working on had been in production.

Hello Steve, The summary is correct for point 1 and 2. About 2b: While it is generally better to have a LDMs with zero ambiguity, it is sometimes not practical. It is often easier to create an LDM with multiple theoretically possible paths. It only becomes a problem when a Visulization is created which actually can be evaluated along multiple paths (it cannot be unambiguously evaluated). In other words: • During metric authoring, the system doesn’t have the full context of how the metric will be used (which datasets will be joined, what filters applied, etc.) • The ambiguity detection needs to analyze the complete query graph, not just the metric definition in isolation However, seems like this gap you are mentioning will be cover in what you saw in the product roadmap.

yes and no. We use the validation on the insights to detect issues, so if what you're saying is true, then the validation of the insight does not cover the ambiguity case which seems like something that should be addressed if we want to validate at the insight level. (unless I miss understand about your query execution plan). For the roadmap, it definitely helps to have the ability to investigate the metric in place without having to use it, hopefully it shows the ambiguity issues which would help.

May I know how are you validating the Analytical Models and insights? Which resources are you using for doing the validations?

We use the API's for each item

Hello Steve, May I know which call do you use to ‘validate each through the API’? Can you provide the specific API call you are using for this?

The process works like the following: • For LDM Validation ◦ The Layout Get and look for any errors in the response • For Analytical Model we run the entity get ◦ with the validation header set to true for ▪︎ all dashboards ▪︎ all visualization objects ▪︎ all metrics ▪︎ all filters

Hello Steve, Thanks for the explanation. I’m assuming that the API is

/api/v1/entities/workspaces/{workspaceId}/metrics

and then you then you include this is in the headers:

X-GDC-VALIDATE-RELATIONS

? This API doesn’t check for ambiguity. We actually don’t have a way to validate AM, the only possible way is to use Python SDK. As explained here: https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1758818459612239 Therefore, I’ll submit Product Feedback on your behalf.

🎉 New note created.

Correct. We are a .net shop, so we don't use the python sdk because its not something we have in a standard development. But that is potentially changing, so it might be worth looking.