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]

Reply via email to