[BUG] ISM types lastUpdatedTime is susceptible to int overflow

[nmck257]

What is the bug?

Policy and IsmTemplate have fields called lastUpdatedTime, stored as an Integer.
These fields get epoch millis as their values, which are larger than MAX_INTEGER.

opensearch-java/java-client/src/generated/java/org/opensearch/client/opensearch/ism/Policy.java

Line 159 in a903ddf

public final Integer lastUpdatedTime() {

opensearch-java/java-client/src/generated/java/org/opensearch/client/opensearch/ism/IsmTemplate.java

Line 103 in a903ddf

public final Integer lastUpdatedTime() {

How can one reproduce the bug?

Use OpenSearchIsmClient and try to GET a policy.

What is the expected behavior?

Successful GET, successful deserialization.

What is your host/environment?

Windows 11, opensearch-java 3.6.0

Do you have any screenshots?

N/A

Do you have any additional context?

If using a JacksonJsonpMapper, then I get an exception like this:

Caused by: com.fasterxml.jackson.core.exc.InputCoercionException: Numeric value (1772134315305) out of range of int (-2147483648 - 2147483647)
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column: 253]

Using Jackson config like DeserializationFeature.USE_BIG_INTEGER_FOR_INTS does not help, because the target type (eg Policy) explicitly has an an Integer type.

If using a JsonbJsonpMapper, then the value silently overflows and I get a negative timestamp.

[andrross]

Catch All Triage - 1 2