[BUG] Unit test failure - testNextTimeToExecution FAILED

[peternied]

Describe the bug
org.opensearch.jobscheduler.spi.schedule.IntervalScheduleTests > testNextTimeToExecution FAILED
java.lang.AssertionError: expected:<PT33.55S> but was:<PT1M33.55S>

To Reproduce
Steps to reproduce the behavior:

1. Command to repro ./gradlew ':opensearch-job-scheduler-spi:test' --tests "org.opensearch.jobscheduler.spi.schedule.IntervalScheduleTests.testNextTimeToExecution" -Dtests.seed=44E256B30E637C7 -Dtests.security.manager=false -Dtests.locale=ja-JP-u-ca-japanese-x-lvariant-JP -Dtests.timezone=Pacific/Wallis

Resulting output

> Task :opensearch-job-scheduler-spi:test
[0.006s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096
[0.005s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096

REPRODUCE WITH: ./gradlew ':opensearch-job-scheduler-spi:test' --tests "org.opensearch.jobscheduler.spi.schedule.IntervalScheduleTests.testNextTimeToExecution" -Dtests.seed=44E256B30E637C7 -Dtests.security.manager=false -Dtests.locale=ja-JP-u-ca-japanese-x-lvariant-JP -Dtests.timezone=Pacific/Wallis -Druntime.java=14

org.opensearch.jobscheduler.spi.schedule.IntervalScheduleTests > testNextTimeToExecution FAILED
    java.lang.AssertionError: expected:<PT33.55S> but was:<PT1M33.55S>
        at __randomizedtesting.SeedInfo.seed([44E256B30E637C7:E28A28442F50C15E]:0)
        at org.junit.Assert.fail(Assert.java:88)
        at org.junit.Assert.failNotEquals(Assert.java:834)
        at org.junit.Assert.assertEquals(Assert.java:118)
        at org.junit.Assert.assertEquals(Assert.java:144)
        at org.opensearch.jobscheduler.spi.schedule.IntervalScheduleTests.testNextTimeToExecution(IntervalScheduleTests.java:73)

Reproduced on my local machine and on the build machine in arm64 environment.

[adityaj1107]

This is not a recently added change. Interesting to know why is this breaking the build for the 1.1 release and was not an issue earlier.

[peternied]

Is this is a test bug or a product bug? New configuration, Is it possible this is a new locale or time zone consideration? Can you reproduce locally?

This impacts the stability of 1.1.0 so we will need to get it resolved. Note, if this is a test bug, you could disable it to quickly get unblocked.

[bowenlan-amzn]

@peternied How do you run test when you first discovered this problem? For me, if running test with locale param -Dtests.locale=ja-JP-u-ca-japanese-x-lvariant-JP, it always fail because some date is not parsed right then. But if just run without any params, it can pass.

For why date is not parsed right, it's prob because this line, SimpleDateFormat should takes in the right locale.

[dbwiddis]

This was fixed in #61 by adding Locale.ROOT to the SimpleDateFormat as @bowenlan-amzn suggested above.