Return lock information from List Jobs API to see if Job has active/released lock

[Jeremydupras]

Description

Adds lock information to the Existing Job information API. Lock information includes. Index name, lock time, job ID, lock duration, and released status. See an example output below.

Related Issues

This will be used as a method to get the currently executing jobs.

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.

{
  "nodes": [
    {
      "node_id": "Oiw0UMt6R6G1IPb4MAyenQ",
      "node_name": "opensearch-node1",
      "scheduled_job_info": {
        "total_jobs": 0,
        "jobs": []
      }
    },
    {
      "node_id": "GBzll_s3QcyEzyAcTB9COQ",
      "node_name": "opensearch-node2",
      "scheduled_job_info": {
        "total_jobs": 1,
        "jobs": [
          {
            "job_type": "scheduler_sample_extension",
            "job_id": "jobid1",
            "index_name": ".scheduler_sample_extension",
            "name": "saple-job-it",
            "descheduled": false,
            "enabled": true,
            "enabled_time": "1970-07-22T20:08:46.833Z",
            "last_update_time": "1970-07-22T20:08:46.833Z",
            "last_execution_time": "2025-07-14T22:38:46.835317291Z",
            "last_expected_execution_time": "2025-07-14T22:38:46.833192593Z",
            "next_expected_execution_time": "2025-07-14T22:39:46.833192593Z",
            "schedule": {
              "type": "interval",
              "start_time": "1970-07-22T20:08:46.833Z",
              "interval": 1,
              "unit": "Minutes",
              "delay": "none"
            },
            "lock": [
              {
                "job_index_name": ".scheduler_sample_extension",
                "lock_time": "2025-07-14T22:38:46.000Z",
                "job_id": "jobid1",
                "lock_duration_seconds": 120,
                "released": true
              }
            ],
            "jitter": "none"
          }
        ]
      }
    }
  ],
  "failures": [],
  "total_jobs": 1
}

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 50 lines in your changes missing coverage. Please review.

Project coverage is 32.56%. Comparing base (638072c) to head (5b633a3).

Files with missing lines	Patch %	Lines
...nsport/action/TransportGetScheduledInfoAction.java	0.00%	50 Missing ⚠️

❌ Your project status has failed because the head coverage (32.56%) is below the target coverage (75.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #799      +/-   ##
============================================
- Coverage     33.54%   32.56%   -0.99%     
  Complexity      143      143              
============================================
  Files            29       29              
  Lines          1389     1431      +42     
  Branches        132      135       +3     
============================================
  Hits            466      466              
- Misses          886      928      +42     
  Partials         37       37              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cwperks]

I see an IndexOutOfBoundsException in the multi-node test check:

SampleJobRunnerRestIT > testActiveLockResponseInScheduledInfoByNode FAILED
    java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
        at __randomizedtesting.SeedInfo.seed([95DF93F641EECDA0:4762E0C1F1294900]:0)
        at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
        at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
        at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
        at java.base/java.util.Objects.checkIndex(Objects.java:385)
        at java.base/java.util.ArrayList.get(ArrayList.java:427)
        at org.opensearch.jobscheduler.sampleextension.SampleJobRunnerRestIT.lambda$new$3(SampleJobRunnerRestIT.java:295)
        at org.opensearch.jobscheduler.sampleextension.SampleJobRunnerRestIT.waitUntilLockIsAcquiredAndReleasedTransportCall(SampleJobRunnerRestIT.java:281)
        at org.opensearch.jobscheduler.sampleextension.SampleJobRunnerRestIT.testActiveLockResponseInScheduledInfoByNode(SampleJobRunnerRestIT.java:206)

[cwperks]

Let's inject the LockService into the constructor and then call findLock like this: https://github.com/opensearch-project/job-scheduler/blob/main/spi/src/main/java/org/opensearch/jobscheduler/spi/utils/LockService.java#L157

[cwperks]

FYI ActionListener is similar to a Promise in JavaScript where you have to define the success and failure case.

In this method actionGet behaves similar to await in JavaScript where it blocks the thread and awaits results of the async call. We should use async calls here to not be blocking.

[cwperks]

I think it makes sense to have 2 separate APIs here to avoid the blocking operations like actionGet and CountDownLatch.

wdyt about separating out list lock into a separate API? In the API handler for listing the locks, let's use the scroll API to get all records in the index.