Update aggregated conversion node to only have queried linkable specs

[WilliamDee]

Context

When you try to query a conversion metric by supplying a filter with a dimension that exists in the base measure's semantic model without providing it in the group by, the rendering fails. This is because with the logic in the conversion metric builder, it ended up "requiring" all the linkable specs from the query (group by + filter), so the group by provided in the filter gets added to the resulting SELECT even though it was not supplied in the group by. This caused an error with the join as it didn't expect that additional element. This PR updates it so that instead of using all the required linkable specs, we should only use the queried linkable specs when building out the conversion aggregate node.

Resolves #1210

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[courtneyholcomb]

Sweet! Can we add a test?

[WilliamDee]

Sweet! Can we add a test?

Oh ya i was just wondering if this looked good first!

[tlento]

The predicate pushdown is failing on snapshots. The other error is a plan conversion failure.

[tlento]

One of the things I love most about GitHub is how they don't allow me to comment on lines that haven't been modified. Seriously, have these people ever even reviewed code before?

Anyway, this does not work because of line 269 above. The queried_linkable_specs do not include any filter specs. So if you don't include required_local_linkable_specs you miss out on propagating any specs requested as filter elements that originate in the base measure dataset.

That's why the missing spec assertion is tripping in that conversion metric test. When we try to run a query that filters on visit__referrer_id, which is local to the base measure, that only gets added to the set of required local specs generated on line 269.

I do not know how to fix this while also fixing the other issue you're trying to resolve here. I don't even know if that's possible without a major overhaul to how we deal with filters. That said, it might be worth postponing a fix for this, since it's not clear to me what our filter behaviors against these nodes are meant to be. There are some fuzzy edge cases around applying a filter to two parts of a conversion calculation, and my sense is we do not correctly differentiate between input-measure-level filters and query-level filters, so whatever we do is going to produce unexpected results for somebody.

[WilliamDee]

Since the issue here was that the final aggregated conversion node had the extraneous group bys, could we just pass the final aggregated node through a FilterElementNode instead of fixing it like this?

[tlento]

Maybe? To be honest, I don't even know what's supposed to happen here, much less whether or not removing that column from the base output will solve this problem in a reasonable way.

The basic question here is how should query-time filters get applied? If I run a query for conversions computed as visits / buys, and I filter to something like WHERE visit__referrer_id = 1234 OR buy__coupon_id = 1234 in order to get all conversions from partner ID 1234, what is supposed to happen? If I add a filter to a conversion measure input to exclude buyer__is_campaign_sourced for our organic_reach_conversion metric, what should happen? What should happen if I apply the query-time filter for partner 1234 with the organic_reach_conversion metric?

I don't think we ever answered these questions, and while some of them are pretty obvious (the organice_reach_conversion filter should be properly applied) the others are less obvious to me, and I think there are a few where it really is just a product decision around how we want this to behave and what kind of traade-offs our users will have in the configuration experience.