capistrant commented on a change in pull request #10676:
URL: https://github.com/apache/druid/pull/10676#discussion_r604468403
##########
File path:
integration-tests/src/test/java/org/apache/druid/tests/indexer/ITCombiningFirehoseFactoryIndexTest.java
##########
@@ -59,13 +61,28 @@ public void testIndexData() throws Exception
throw new RuntimeException(e);
}
};
+ final Function<String, String> transform = spec -> {
+ try {
+ return StringUtils.replace(
+ spec,
+ "%%SEGMENT_AVAIL_TIMEOUT_MILLIS%%",
+ jsonMapper.writeValueAsString("0")
Review comment:
> Some comments on this pattern since I've seen it across a few tests
>
> * Does this change mean we lose coverage on a missing
`SEGMENT_AVAIL_TIMEOUT_MILLIS`? Since this is the default mode, it would be
good to have coverage for that missing change
There IT tests out there that indirectly test this. By indirectly, I mean
that I did not add the tests but the tests do not have the config in the
tuningConfig. For instance,
https://github.com/capistrant/incubator-druid/blob/batch-ingest-wait-for-handoff/integration-tests/src/test/java/org/apache/druid/tests/indexer/ITIndexerTest.java#L146,
is an index job that doesn't add the transform and the underlying spec file
does not have the config in it.
https://github.com/capistrant/incubator-druid/blob/batch-ingest-wait-for-handoff/integration-tests/src/test/resources/indexer/wikipedia_reindex_task.json#L49
> * Do we have / want tests where this is set to a high enough number that
we don't need a re-try loop in the integration tests while waiting for the
segments to be available
technically that retry loop is redundant in the case that the test uses
`true,true` for the `Pair` object that determines if we should check the
ingestion report for `true` as the value for the handoff. this would be an
example of that,
https://github.com/capistrant/incubator-druid/blob/batch-ingest-wait-for-handoff/integration-tests/src/test/java/org/apache/druid/tests/indexer/ITIndexerTest.java#L205
--
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]
