[Bug]: GROUP BY on two nullable LONGTEXT keys fails after width overflow #30997

Is there an existing issue for the same bug?

• I have checked the existing issues.

Branch Name

main

Commit ID

b787941

Other Environment Information

• Linux amd64; local distributed LOG/TN/CN deployment.
• The reproduction uses only five tiny rows. No large strings or memory pressure are required.
• The same faulty width calculation remains in main 156b7cc (source inspection).

Actual Behavior

Grouping two nullable LONGTEXT columns fails with SQL error 20101 and a recovered nil-pointer panic. The stack reaches Group.Prepare -> prepareGroupAndAggArg -> createNewGroupByBatchWithAllocation -> nil Vector.GetType. The same failure is reachable with two STORED LONGTEXT JSON projections, which exposed it during complete AgentLogs query validation.

Expected Behavior

The query returns three groups, with counts 2, 2, and 1 respectively, without a panic.

Steps to Reproduce

create database group_width_repro;
use group_width_repro;
create table t(a longtext, b longtext, latency int not null);
insert into t values
  ('a','x',10),('a','x',30),('b','y',20),
  (null,'y',40),(null,'y',60);
select a,b,count(*) as observations,avg(latency) as avg_latency
from t group by a,b order by a is not null,a,b;

Expected rows:

NULL  y  2  50.0000
a     x  2  20.0000
b     y  1  20.0000

Additional information

GetKeyWidth adds the NULL marker to declared width 2147483647. Narrowing 2147483648 to int32 wraps negative, and adding two such estimates wraps to zero. Preparation incorrectly selects H0 (no grouping keys) and attempts to build its dummy group before the actual key vectors have been evaluated. Other wrapped wide estimates can also incorrectly qualify for legacy H8.

The proposed narrow correction saturates the static width estimate before narrowing/addition and selects H0 from the actual grouping-key count. It preserves exact small widths, existing H8/HStr codecs and rollout gates. It does not change stored data, hash grammar, spill policy or allocation ownership.

An original-source Go overlay reproduces the panic; the corrected code passes independent exact-group/count tests, same-operator reuse, and actual partial Group -> MergeGroup execution under both v77 and v78 gates. Ordinary and STORED SQL reproductions and all twenty AgentLogs queries pass on the isolated corrected binary. Final delivery validation is tracked in the linked pull request.