Allow timestamp-index derived columns in star-tree dimensionsSplitOrder validation

[himanish-star]

Problem

A table config that references timestamp-index derived columns (\$<column>\$<GRANULARITY>, e.g. \$OrderDate\$DAY) in starTreeIndexConfigs[].dimensionsSplitOrder is rejected by TableConfigUtils validation with:

Failed to find dimension column: $OrderDate$DAY specified in star-tree index config in schema

These derived columns are declared via fieldConfigList[].timestampConfig.granularities and are materialized as dictionary-encoded, single-value TIMESTAMP columns at segment generation time (TimestampIndexUtils#applyTimestampIndex). They are therefore absent from the schema during config validation, even though the configuration is valid and works at runtime. Today the only workaround is to push the config through the REST API with validation skipped.

Fix

validateStarTreeIndexConfigs now receives the set of declared timestamp-index columns (TimestampIndexUtils#extractColumnsWithGranularity) and accepts them in dimensionsSplitOrder without a schema lookup — matching how they are handled at segment generation time. Columns whose granularity is not declared in timestampConfig are still rejected.

Testing

Added TableConfigUtilsTest#testValidateStarTreeIndexWithTimestampIndexDerivedColumns:

• A star-tree config using \$OrderDate\$DAY/WEEK/MONTH with matching timestampConfig granularities now validates.
• A star-tree dimension referencing an undeclared granularity (\$OrderDate\$HOUR) still fails validation.

checkstyle:check and license:check pass on pinot-segment-local.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.78%. Comparing base (b27a3ad) to head (eae9d21).
⚠️ Report is 10 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master   #18774   +/-   ##
=========================================
  Coverage     64.78%   64.78%           
  Complexity     1309     1309           
=========================================
  Files          3380     3380           
  Lines        209544   209561   +17     
  Branches      32797    32802    +5     
=========================================
+ Hits         135746   135758   +12     
- Misses        62870    62875    +5     
  Partials      10928    10928           

Flag	Coverage Δ
custom-integration1	100.00% <ø> (ø)
integration	100.00% <ø> (ø)
integration1	100.00% <ø> (ø)
integration2	0.00% <ø> (ø)
java-21	64.78% <100.00%> (+<0.01%)	⬆️
temurin	64.78% <100.00%> (+<0.01%)	⬆️
unittests	64.77% <100.00%> (+<0.01%)	⬆️
unittests1	56.95% <22.22%> (+<0.01%)	⬆️
unittests2	37.28% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Vamsi-klu]

Walked through the three guards in validateStarTreeIndexConfigs: the first-loop indexConfigsMap.get(dimension) dictionary check, the Iterables.concat MAP check, and the dimensionColumns single-value check now all short circuit when the column is in timestampIndexColumns, so $OrderDate$DAY no longer trips the Failed to find dimension column precondition. I like that the allowed set comes from extractColumnsWithGranularity rather than an isValidColumnWithGranularity shape match, since that's exactly what keeps $OrderDate$HOUR in the negative test rejected instead of blanket accepted (HOUR is a valid granularity token but was never declared on OrderDate). It also lines up with what applyTimestampIndex materializes into the schema at segment build time, so config validation and runtime agree. One note: the derived branch skips the dictionary precondition too, which reads fine since these get generated as dictionary encoded. This looks right to me.