[BUG] ISM API - Put Policies: `java.lang.RuntimeException: Jackson exception: Numeric value out of range of int (-2147483648 - 2147483647)`

What is the bug?

When attempting to make a PutPolicyRequest, the following exception is thrown:

java.lang.RuntimeException: Jackson exception: Numeric value (1755915614485) out of range of int (-2147483648 - 2147483647)
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column: 342]

However, the policy is saved. It appears that some numeric value, likely a timestamp, is triggering a validation error. I am currently not specifying any time values explicitly.

How can one reproduce the bug?

I tried to use the ISM code to add a simply policy based on this example:
https://docs.opensearch.org/latest/im-plugin/ism/policies/#sample-policy-with-ism-template-for-auto-rollover

A snippet of my code is below:

IsmTemplate getIsmTemplate() {
      return IsmTemplate.builder()
          .lastUpdatedTime(1)
          .indexPatterns(getIndexMatchingPattern())
          .build();
}

List<States> getStates() {
      var rollover = Action.builder()
          .rollover(ActionRollover.builder()
              .minDocCount(MAX_RECORDS)
              .build())
          .build();
      return List.of(
          States.builder()
              .name(IndexState.WRITEABLE.name)
              .actions(rollover)
              .build()
      );
}

/* ... */
var p = Policy.builder()
            .states(getStates())
          .policyId(<id>)
          .defaultState(IndexState.WRITEABLE.name)
          .ismTemplate(getIsmTemplate());

var policyReq = PutPoliciesRequest.builder()
          .policy(_p -> p)
          .policyId(r.getId())
          .build();
var policyRes = client.ism().putPolicies(policyReq); // THROWS HERE

What is the expected behavior?

The expected behavior would be that client.ism().putPolicies should not throw.

What is your host/environment?

Windows 11

Do you have any screenshots?

Stacktrace of the exception showing that the call to putPolicies fails:

Do you have any additional context?

The number that is out of range seems to be a unix epoch description. Perhaps one of the fields in the request object needs to be changed to a type that can fit the number?

Start by tracing PutPoliciesRequest and the ISM policy model through the Java client’s Jackson handling, focusing on the timestamp-like value reported in the exception. Reproduce the sample policy request, identify the field whose type cannot hold the epoch value, and add or update a regression test showing that client.ism().putPolicies no longer throws.