capistrant commented on a change in pull request #10676:
URL: https://github.com/apache/druid/pull/10676#discussion_r604464490
##########
File path:
integration-tests/src/test/java/org/apache/druid/tests/indexer/AbstractITBatchIndexTest.java
##########
@@ -280,6 +334,18 @@ private void submitTaskAndWait(
);
}
+ if (segmentAvailabilityConfirmationPair.lhs != null &&
segmentAvailabilityConfirmationPair.lhs) {
+ TaskReport reportRaw =
indexer.getTaskReport(taskID).get("ingestionStatsAndErrors");
+ IngestionStatsAndErrorsTaskReport report =
(IngestionStatsAndErrorsTaskReport) reportRaw;
+ IngestionStatsAndErrorsTaskReportData reportData =
(IngestionStatsAndErrorsTaskReportData) report.getPayload();
+ if (segmentAvailabilityConfirmationPair.rhs != null) {
+ Assert.assertEquals(
+ Boolean.valueOf(reportData.isSegmentAvailabilityConfirmed()),
+ segmentAvailabilityConfirmationPair.rhs
+ );
+ }
+ }
+
Review comment:
hmm, my gut is that no we don't want to remove that without some
(potentially large) surgery to the indexing IT suite. I added on my own logic
for checking the ingestion report for handoff status. But that is separate from
what other tests are using this loop for. I would bet that the two ideas could
be merged together more gracefully by replacing waitForSegmentsToLoad by using
the new handoff config and waiting for the task to complete and then checking
the report and failing if the report doesn't indicate the segments were loaded.
Not sure if it is in scope for this PR, especially after we revoked support for
the handoff for compaction tasks (unless there are no Compaction IT out there
that use waitForSegmentsToLoad=true, I'd have to check).
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
