Fields are seemingly references by their position in an array about metabase

[bshepherdson]

You're exactly right about what's going on here. In legacy MBQL, aggregation references are done by an index into the aggregations list.

MLv2 (new library and MBQL format) use UUIDs to reference aggregations, avoiding this problem. But legacy is still the source of truth in the appdb and on the wire, so we're not free of this bug yet.

[meldiner]

@bshepherdson, thanks for confirming. Do you expect updating metabase version to resolve this?

[bshepherdson]

I regret to say "not yet". I just checked this with the 0.49 RC and while the behavior has changed slightly (the expression is less broken after making the edit), this has not been fixed.

This is one of the diverse symptoms of a fundamental issue #36185 with how Metabase handles similar but not identical columns. There are lots of other ways to trip over this bug, such as joining the same table twice, or naming a custom column the same as a column from an earlier stage.

When the first aggregation max is deleted, the two surviving ones are renamed from max_2 and max_3 to max and max_2. The expression in the second stage of the query has a reference like [:field "max_2"], which is still valid. We don't currently connect the dots that the artist column formerly known as max_2 is now known as max.

So this won't be fixed in 49 or 50, but fixing that issue is one of my long-term goals. Much of the groundwork for it has landed over the past six months or so, but we're not ready to eliminate this issue yet.