Grouped-aggregate result cache ignores select-list aliases — repeating the query with different labeling returns empty aggregate cells #192

Version / build tested against

origin/main @ eea86b279

Deployment mode

Origin — single node (local)

Engine(s) involved

Document (strict)

Summary

The first grouped-aggregate query on a collection in a session pins a session-scoped cache keyed on the query structure but not the select-list labeling. Re-running the same aggregate with different aliasing — alias removed, or a different alias — returns rows whose aggregate column is empty (group keys still present). Bidirectional and order-independent: whichever labeling runs first poisons the others. A fresh connection resets it. Any workload mixing labelings on one connection — consoles, hand-written SQL, pooled connections shared by different clients — silently gets empty aggregates. Note: v0.4.0's session plan-cache fix (stale point lookups) did not cover this path; retested on eea86b279 same day.

Steps to reproduce

-- fresh data directory, single psql session on 6432
CREATE COLLECTION grp (id TEXT PRIMARY KEY, label TEXT, score FLOAT) WITH (engine='document_strict');
INSERT INTO grp (id, label, score) VALUES ('r1','alpha',7);
INSERT INTO grp (id, label, score) VALUES ('r2','beta',3);

SELECT label, SUM(score) AS s FROM grp GROUP BY label;
--  beta  | 3.0
--  alpha | 7.0        <- first grouped aggregate: correct

SELECT label, SUM(score) FROM grp GROUP BY label;
--  beta  |
--  alpha |            <- same query, alias removed: EMPTY aggregate cells

SELECT label, SUM(score) AS other FROM grp GROUP BY label;
--  beta  |
--  alpha |            <- different alias: still EMPTY

Expected behavior

Select-list aliasing never changes result values. All three queries return the same sums; any internal result/plan cache keys on (or is invalidated by) output labeling.

Actual behavior

First labeling returns correct sums; every subsequent labeling variant in the same session returns empty aggregate cells with no error. Running the unaliased form first poisons the aliased forms instead. Fresh connection resets the behavior.

What actually happened? (check all that are true)

• A workaround exists (rewrite the query, avoid one path, etc.)

Proposed severity

SEV-2 — High: silently-wrong (empty) aggregate results; stored data intact. Workaround: keep one labeling per session or reconnect.

Reproducibility

Always — every attempt

Last known-good version / commit (if a regression)

(blank)

Environment & logs

Linux x86_64, release build. Simple protocol via psql; also reproduces through the extended protocol.

Before submitting

• I searched existing issues and this is not a duplicate.
• I reproduced this on a released tag or a current main build (not a stale local branch).
• This is not a security vulnerability (those go to a private advisory).