### What happened?

When Job controller is deleting pods the counter in the status.ready field does not reflect this properly (there is a delay until the cache is refreshed). This affects the scenarios of terminating job, suspended job, and excess pods deleted.

### What did you expect to happen?

The ready field is updated as soon as the delete requests are sent successfully, in sync with the status.active field.

### How can we reproduce it (as minimally and precisely as possible)?

1. To see this you can scale down a job, use the following yaml:
```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: simple-job
spec:
  completions: 2
  parallelism: 2
  completionMode: Indexed
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: 'worker'
        image: python
        command:
        - python3
        - -c
        - |
          import time
          time.sleep(300)
```

2. Watch for the job updates with the following watcher:
```
kubectl get jobs -w --output-watch-events -ocustom-columns=EVENT:.type,NAME:.object.metadata.name,READY:.object.status.ready,ACTIVE:.object.status.active,TERMINATING:.object.status.terminating,CONDITIONS:.object.status.conditions | ts "%Y-%m-%d %H:%M:%.S"`
```
3. Scale down the job by `kubectl edit job` and decrease parallelism and completions to 1.

We observe events like the following
```
2024-05-29 12:49:58.790101 ADDED     simple-job   <none>   <none>   <none>        <none>
2024-05-29 12:49:58.810008 MODIFIED   simple-job   0        2        0             <none>
2024-05-29 12:50:02.065710 MODIFIED   simple-job   2        2        0             <none>
2024-05-29 12:50:17.526562 MODIFIED   simple-job   2        2        0             <none>
2024-05-29 12:50:17.542893 MODIFIED   simple-job   2        1        0             <none>
2024-05-29 12:50:18.537404 MODIFIED   simple-job   1        1        1             <none>
2024-05-29 12:50:48.785143 MODIFIED   simple-job   1        1        0             <none>
2024-05-29 12:55:01.515515 MODIFIED   simple-job   0        1        0             <none>
2024-05-29 12:55:02.519571 MODIFIED   simple-job   0        <none>   0             <none>
2024-05-29 12:55:02.529433 MODIFIED   simple-job   0        <none>   0             [map[lastProbeTime:2024-05-29T10:55:02Z lastTransitionTime:2024-05-29T10:55:02Z status:True type:Complete]]
```
Note that for one update at `2024-05-29 12:50:17.542893` ready is `2` while `active` is already `1`. We can set `ready` to `1` at this point already. Note that the pod was terminating for around 30s. 

Also note, that the event at `2024-05-29 12:50:17.542893` has `terminating=0`. This value could be set to `1` already, and this is being addressed in https://github.com/kubernetes/kubernetes/issues/125089.

### Anything else we need to know?

This is related to https://github.com/kubernetes/kubernetes/issues/123775. We need this fix to be able to re-introduce the validation rule that `ready <= active` which was withdrawn here: https://github.com/kubernetes/kubernetes/pull/123792.


The culprit of the issue is that we determine the count of ready pods by filtering active pods [here](https://github.com/kubernetes/kubernetes/blob/afebfdc5d411859468153e2b9921915f3e4f9ff4/pkg/controller/job/job_controller.go#L832). However, the count of active pods might be changed later. 

**Note that**: This issue is slightly more complex than https://github.com/kubernetes/kubernetes/pull/123792. We cannot unconditionally decrement the counter for ready pods based on the number of successfully deleted pods. The functions deleting pods should probably also return the counters of successfully deleted ready pods (along with the count of successfully deleted pods).

### Kubernetes version

<details>
1.30

</details>


### Cloud provider

<details>
Kind
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

Job controller reports the count of ready pods with unnecessary delay
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : Job controller reports the count of ready pods with unnecessary delay
Issue date:

--- start body ---
### What happened?

When Job controller is deleting pods the counter in the status.ready field does not reflect this properly (there is a delay until the cache is refreshed). This affects the scenarios of terminating job, suspended job, and excess pods deleted.

### What did you expect to happen?

The ready field is updated as soon as the delete requests are sent successfully, in sync with the status.active field.

### How can we reproduce it (as minimally and precisely as possible)?

1. To see this you can scale down a job, use the following yaml:
```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: simple-job
spec:
  completions: 2
  parallelism: 2
  completionMode: Indexed
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: 'worker'
        image: python
        command:
        - python3
        - -c
        - |
          import time
          time.sleep(300)
```

2. Watch for the job updates with the following watcher:
```
kubectl get jobs -w --output-watch-events -ocustom-columns=EVENT:.type,NAME:.object.metadata.name,READY:.object.status.ready,ACTIVE:.object.status.active,TERMINATING:.object.status.terminating,CONDITIONS:.object.status.conditions | ts "%Y-%m-%d %H:%M:%.S"`
```
3. Scale down the job by `kubectl edit job` and decrease parallelism and completions to 1.

We observe events like the following
```
2024-05-29 12:49:58.790101 ADDED     simple-job   <none>   <none>   <none>        <none>
2024-05-29 12:49:58.810008 MODIFIED   simple-job   0        2        0             <none>
2024-05-29 12:50:02.065710 MODIFIED   simple-job   2        2        0             <none>
2024-05-29 12:50:17.526562 MODIFIED   simple-job   2        2        0             <none>
2024-05-29 12:50:17.542893 MODIFIED   simple-job   2        1        0             <none>
2024-05-29 12:50:18.537404 MODIFIED   simple-job   1        1        1             <none>
2024-05-29 12:50:48.785143 MODIFIED   simple-job   1        1        0             <none>
2024-05-29 12:55:01.515515 MODIFIED   simple-job   0        1        0             <none>
2024-05-29 12:55:02.519571 MODIFIED   simple-job   0        <none>   0             <none>
2024-05-29 12:55:02.529433 MODIFIED   simple-job   0        <none>   0             [map[lastProbeTime:2024-05-29T10:55:02Z lastTransitionTime:2024-05-29T10:55:02Z status:True type:Complete]]
```
Note that for one update at `2024-05-29 12:50:17.542893` ready is `2` while `active` is already `1`. We can set `ready` to `1` at this point already. Note that the pod was terminating for around 30s. 

Also note, that the event at `2024-05-29 12:50:17.542893` has `terminating=0`. This value could be set to `1` already, and this is being addressed in https://github.com/kubernetes/kubernetes/issues/125089.

### Anything else we need to know?

This is related to https://github.com/kubernetes/kubernetes/issues/123775. We need this fix to be able to re-introduce the validation rule that `ready <= active` which was withdrawn here: https://github.com/kubernetes/kubernetes/pull/123792.


The culprit of the issue is that we determine the count of ready pods by filtering active pods [here](https://github.com/kubernetes/kubernetes/blob/afebfdc5d411859468153e2b9921915f3e4f9ff4/pkg/controller/job/job_controller.go#L832). However, the count of active pods might be changed later. 

**Note that**: This issue is slightly more complex than https://github.com/kubernetes/kubernetes/pull/123792. We cannot unconditionally decrement the counter for ready pods based on the number of successfully deleted pods. The functions deleting pods should probably also return the counters of successfully deleted ready pods (along with the count of successfully deleted pods).

### Kubernetes version

<details>
1.30

</details>


### Cloud provider

<details>
Kind
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

--- end body ---
