Doris-Breakwater commented on issue #68742: URL: https://github.com/apache/doris/issues/68742#issuecomment-5999275107
Breakwater-GitHub-Analysis-Slot: slot_a493a51b0fe9 **Triage:** This is a reproducible IVM create/refresh contract gap on the stated `7ac0eb2fdb4` revision. The supplied SQL and task output are sufficient for initial triage; I have not run a Doris cluster reproduction. **Code evidence:** Normalization permits a project above an aggregate and records each aggregate's own output slot as an `IvmAggTarget` ([normalization project](https://github.com/apache/doris/blob/7ac0eb2fdb426595f810e94ab77b7aa2eece12d5/fe/fe-core/src/main/java/org/apache/doris/nereids/rules/analysis/IvmNormalizeMTMV.java#L364-L374), [target construction](https://github.com/apache/doris/blob/7ac0eb2fdb426595f810e94ab77b7aa2eece12d5/fe/fe-core/src/main/java/org/apache/doris/nereids/rules/analysis/IvmNormalizeMTMV.java#L779-L825)). During incremental apply, `IvmAggSumProcessor` reads the old MV value using that target slot's name ([SUM apply](https://github.com/apache/doris/blob/7ac0eb2fdb426595f810e94ab77b7aa2eece12d5/fe/fe-core/src/main/java/org/apache/doris/mtmv/ivm/agg/IvmAggSumProcessor.java#L49-L62)); the lookup searches the physical MV scan output and throws the reported error if the slot is absent ([slot lookup](https://github.com/apache/doris/blob/7ac0eb2fdb426595f810e94a b77b7aa2eece12d5/fe/fe-core/src/main/java/org/apache/doris/mtmv/ivm/agg/IvmAggExpressionBuilder.java#L94-L107)). In this definition, the target is `sum(v)` while the stored visible column is the outer expression `s100`, so the state the SUM apply step expects is unavailable. The issue's working `COUNT(*)` and `AVG` cases fit the code paths: `COUNT(*)` uses group count, and `AVG` reads hidden SUM/COUNT state ([COUNT apply](https://github.com/apache/doris/blob/7ac0eb2fdb426595f810e94ab77b7aa2eece12d5/fe/fe-core/src/main/java/org/apache/doris/mtmv/ivm/agg/IvmAggCountProcessor.java#L84-L101), [AVG apply](https://github.com/apache/doris/blob/7ac0eb2fdb426595f810e94ab77b7aa2eece12d5/fe/fe-core/src/main/java/org/apache/doris/mtmv/ivm/agg/IvmAggAvgProcessor.java#L53-L74)). This explains the failure mechanism for the reported case; the other listed expressions still need regression coverage. **Recommended next step:** Add create-time validation that every aggregate state the incremental apply processors read is actually persisted in the MV schema. Reject unsupported outer expressions with a clear analysis error unless the required aggregate state is also stored. If supporting these expressions, persist the missing aggregate states and recompute the outer expression from their updated values; simply treating `s100` as the old `sum(v)` would produce incorrect results. Cover `SUM(v) * 100`, `COUNT(v) + 1`, `MIN`/`MAX`, `COLLECT_LIST`, and the working `COUNT(*)`/`AVG`/bare-aggregate cases in create and strict incremental refresh tests. A `COMPLETE` refresh (or `INCREMENTAL FALLBACK`, which the report shows chooses `COMPLETE`) is the current operational workaround. **Missing information:** None needed to locate the reported planning failure. A maintainer reproducing it should capture `SHOW CREATE MATERIALIZED VIEW`, the physical MV column list, and `EXPLAIN REFRESH MATERIALIZED VIEW ... INCREMENTAL` alongside the task error to confirm the schema/plan boundary on the target build. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
