getSLOHistory fails with SLO type time-slice

[Alexander Davis]

Describe the bug

getSLOHistory fails to retrieve SLO History for time-slice SLOs, with the following error:

Caused by: com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot coerce String value ("NO_DATA") to `java.lang.Double` value (but might if coercion using `CoercionConfig` was enabled)
 at [Source: (org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream); line: 1, column: 971] (through reference chain: com.datadog.api.client.v1.model.SLOHistoryResponse["data"]->com.datadog.api.client.v1.model.SLOHistoryResponseData["overall"]->com.datadog.api.client.v1.model.SLOHistorySLIData["history"]->java.util.ArrayList[0]->java.util.ArrayList[1])

Only SLOs of type time-slice are affected.

To Reproduce
Steps to reproduce the behavior:

We followed the most minimal example from the SLO API documentation:

ApiClient defaultClient = ApiClient.getDefaultApiClient();
ServiceLevelObjectivesApi apiInstance = new ServiceLevelObjectivesApi(defaultClient);

ServiceLevelObjectivesApi.GetSLOHistoryOptionalParameters parameters = new ServiceLevelObjectivesApi.GetSLOHistoryOptionalParameters().target(99.9).applyCorrection(false);

SLOHistoryResponse result = apiInstance.getSLOHistory(
    "asdf4567asdf7890, "// Some String SLO ID of type time-slice
    OffsetDateTime.now().plusDays(-7).toInstant().getEpochSecond(),
    OffsetDateTime.now().toInstant().getEpochSecond(),
    parameters
);

Expected behavior

apiInstance.getSLOHistory() should return an object of type SLOHistoryResponse.

This currently works for all SLOs in our environment except SLOs of type time-slice. This remains true even if we remove the .target() and .applyCorrection optional parameters from the query.

Environment and Versions (please complete the following information):
A clear and precise description of your setup:

• v2.21.0 of the Java datadog-api-client

[skarimo]

Hello, thanks for the report! We are looking into this and will follow up with our findings.

[github-actions]

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community.

If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of this project.

2. Comment that the issue is still reproducible and include updated details requested in the issue template.