[CI] DataStreamAndIndexLifecycleMixingTests testUpdateIndexTemplateToDataStreamLifecyclePreference failing

[elasticsearchmachine]

Build Scans:

• elasticsearch-intake #28308 / part2
• elasticsearch-periodic-platform-support #10532 / rhel-9_platform-support-unix
• elasticsearch-periodic #10506 / openjdk23_checkpart2_java-matrix

Reproduction Line:

./gradlew ":x-pack:plugin:ilm:internalClusterTest" --tests "org.elasticsearch.xpack.ilm.DataStreamAndIndexLifecycleMixingTests.testUpdateIndexTemplateToDataStreamLifecyclePreference" -Dtests.seed=7D1A9FCDD1FEA2D3 -Dtests.locale=km-KH -Dtests.timezone=Africa/Asmara -Druntime.java=24

Applicable branches:
8.19

Reproduces locally?:
N/A

Failure History:
See dashboard

Failure Message:

java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3

Issue Reasons:

• [8.19] 3 failures in test testUpdateIndexTemplateToDataStreamLifecyclePreference (0.8% fail rate in 398 executions)

Note:
This issue was created using new test triage automation. Please report issues or feedback to es-delivery.

[elasticsearchmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[nielsbauman]

Looking at the logs of some test failures (e.g. this one), I see that the index gets deleted by DLM due to a very short retention:

[2025-09-08T00:47:21,306][INFO ][o.e.d.l.DataStreamLifecycleService][node_s1][clusterApplierService#updateTask][T#1] Data stream lifecycle successfully deleted index [.ds-datastream-rfgeclyfgrnr-2025.09.08-000003] due to the lapsed [460micros] retention period

which is defined here:

elasticsearch/x-pack/plugin/ilm/src/internalClusterTest/java/org/elasticsearch/xpack/ilm/DataStreamAndIndexLifecycleMixingTests.java

Line 161 in fc5a7ef

.dataRetention(randomPositiveTimeValue())

Although we already used a random retention before #124593, that PR increases the chance of a too-low retention, as we used randomMillisUpToYear9999() before and now we use randomPositiveTimeValue(). The cutoff of what is too low for a retention value is probably around a few seconds, which is a tiny part of randomMillisUpToYear9999(), whereas it is much more likely in what randomPositiveTimeValue() does:

new TimeValue(between(1, 1000), randomFrom(TimeUnit.values()));

The fix is conceptually pretty straightforward; just ensure that the retention is not smaller than a few seconds. But I'll take a second to think of a good generic solution, as #124593 touches quite a few tests where this could occur.