Skip to content

Conversation

@toepkerd
Copy link
Collaborator

Description

[Describe what this change achieves]

Related Issues

Resolves #[Issue number to be closed when this PR is merged]

Check List

  • New functionality includes testing.
  • New functionality has been documented.
  • API changes companion pull request created.
  • Commits are signed per the DCO using --signoff.
  • Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

manual: Boolean, // if execute was called by user or by scheduled job
monitorV2Id: String?,
monitorV2: MonitorV2?,
requestStart: TimeValue? = null,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went through the code, this is not actually used. It is only used once to compare this with requestEnd and if they are the same, it throws an exception. Based on that, we should just remove requestStart. This was needed in v1 monitors because query level and bucket level monitors lets you run the monitor execution within a specified time window. That does not happen for ppl monitors.

Comment on lines 27 to 28
monitorV2Id: String?,
monitorV2Ids: List<String>? = null,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Blocking since decides the APIs and we can just go back on it] Why not just use monitorV2Ids here? If it is just one id, it can still be put into monitorV2Ids

val scheduledJob = ScheduledJob.parse(xcp, getResponse.id, getResponse.version)

validateMonitorV1(scheduledJob)?.let {
actionListener.onFailure(AlertingException.wrap(it))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should throw an exception that says trying to delete a v2 monitor using the v1 monitor and to use the v2 api.

Copy link
Member

@lezzago lezzago Oct 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should do the same for the other v1 apis

Copy link
Collaborator Author

@toepkerd toepkerd Oct 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The validateMonitorV1 and validateMonitorV2 functions returns exactly such an error, and calls onFailure with that error (wrapped in AlertingException)

Reference: https://github.com/toepkerd/alerting/blob/6da2c587c1def4dc29c655bdf02b484e6b605993/alerting/src/main/kotlin/org/opensearch/alerting/AlertingV2Utils.kt#L39

)
return ScheduledJob.parse(xcp, getResponse.id, getResponse.version) as Workflow
val scheduledJob = ScheduledJob.parse(xcp, getResponse.id, getResponse.version)
validateMonitorV1(scheduledJob)?.let {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we update the function name to include workflows to make it clear?

}

// Checks if the exception is caused by an IndexNotFoundException (directly or nested).
private fun isIndexNotFoundException(e: Exception): Boolean {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this not used?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is moved to AlertingV2Utils. The PR to add (copy) it to AlertingV2Utils is merged, so the diff shows the deletion of it from where the function originally came from.

Comment on lines 115 to 147
fun getEmptySearchResponse(): SearchResponse {
val internalSearchResponse = InternalSearchResponse(
SearchHits(emptyArray(), TotalHits(0L, Relation.EQUAL_TO), 0.0f),
InternalAggregations.from(Collections.emptyList()),
Suggest(Collections.emptyList()),
SearchProfileShardResults(Collections.emptyMap()),
false,
false,
0
)

return SearchResponse(
internalSearchResponse,
"",
0,
0,
0,
0,
ShardSearchFailure.EMPTY_ARRAY,
SearchResponse.Clusters.EMPTY
)
}

// Checks if the exception is caused by an IndexNotFoundException (directly or nested).
private fun isIndexNotFoundException(e: Exception): Boolean {
if (e is IndexNotFoundException) return true
if (e is RemoteTransportException) {
val cause = e.cause
if (cause is IndexNotFoundException) return true
}
return false
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this not used?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is moved to AlertingV2Utils. The PR to add (copy) it to AlertingV2Utils is merged, so the diff shows the deletion of it from where the function originally came from.

// get execution time interval
val (periodStart, periodEnd) = if (execMonitorV2Request.requestStart != null) {
Pair(
Instant.ofEpochMilli(execMonitorV2Request.requestStart.millis),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

requestStart is not needed since it isn't really used.

@toepkerd toepkerd force-pushed the ppl-main branch 2 times, most recently from f43af57 to 7538f94 Compare November 2, 2025 18:43
Signed-off-by: Dennis Toepker <toepkerd@amazon.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants