https://graphite.readthedocs.io/en/latest/functions.html#graphite.render.functions.summarize doesn't mention cnt, only count. does graphite support it without documenting it?

Supported functions in graphite are defined here: https://github.com/graphite-project/graphite-web/blob/master/webapp/graphite/render/functions.py#L261-L281

I think adding support for count to FromConsolidateBy is the right move here, but i don't see what we gain by allowing cnt (other than just in general being more lenient for no particular reason, but graphite doesn't allow it so perhaps we shouldn't either)

Keeping cnt is a compatibility measure for consolidateBy since it's been allowed as "Bonus" for a while (looks like ~3 years).

But it looks like it could never be used, assuming everything was calling Validate first.

since it's been allowed as "Bonus" for a while (looks like ~3 years)

hmm this is based on what you saw in consolidation.FromConsolidateBy() ?

But it looks like it could never be used, assuming everything was calling Validate first.

yes we validate before invoking the function using IsConsolFunc which calls consolidation.Validate which doesn't allow cnt

currently, in metrictank, for every caller of consolidation.FromConsolidateBy(<foo>), <foo> has been validated via IsConsolFunc, so <foo> would never have the value cnt.

to improve our interop with graphite (e.g. queries that work on just MT should still work when switching to graphite), let's remove the allowance for cnt consolidation.FromConsolidateBy() which we now is never used anyway.

I am open to allowing cnt as "syntactic sugar" (that was the goal initially anyway), but we should only do it if it's also made its way into graphite