yujun777 commented on code in PR #68390:
URL: https://github.com/apache/doris/pull/68390#discussion_r4092416896
##########
fe/fe-core/src/main/java/org/apache/doris/job/extensions/mtmv/MTMVTask.java:
##########
@@ -510,9 +579,44 @@ && hasUnusableIvmStream()) {
mtmv.getName(), getTaskId());
return Lists.newArrayList(RefreshAttemptType.COMPLETE);
}
+ // Every partition either needs a rebuild or was never filled, and at
least one needs a rebuild:
+ // COMPLETE then does nothing the per-partition routing would not, in
one read of the MV.
+ if (!request.explicitPartitions &&
attempts.contains(RefreshAttemptType.IVM)
Review Comment:
Fixed in a90f53e5f41: the shortcut is gated on `request.allowFallback`, as
you suggest, and the stream shortcut above it is unchanged. What that leaves is
the contract you named: a strict `INCREMENTAL` reaches the incremental attempt,
which rebuilds every one of those partitions and finds nothing left to catch up
-- and fails there when a stream is unusable, instead of resetting it. AUTO
(manual or scheduled) and every explicit `FALLBACK` default to allowing one
(`MTMVRefreshInfo.defaultAllowFallback`), so the shortcut still applies to
them; the only request whose outcome changes is the manual `INCREMENTAL`
without `FALLBACK`.
On the test: the unit test pins the decision in both directions -- strict
keeps `[IVM]`, fallback takes `[COMPLETE]` -- and removing the gate makes it
fail with `expected: <[IVM]> but was: <[COMPLETE]>`. The end-to-end combination
you asked for (all-dirty plus an unusable stream, `INCREMENTAL` without
`FALLBACK`) I did not add as its own case: the consequence is the incremental
attempt's existing behaviour on an unusable stream, which
`test_ivm_partitions_fallback_stream_unusable` already covers, and the
all-dirty state has its own suite
(`test_ivm_partitions_after_failed_complete`). Say the word and I will put the
two together in that suite.
--
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]