RTF restart via REST API returns HTTP 202 but no restart occurs — no pod changes, no event in Runtime Manager, nothing visible on the cluster.

Root Cause

The RTF agent creates an ephemeral Kubernetes Job (activeDeadlineSeconds: 300) to execute the restart. That Job requires rtf-mule-actions:2.0.20, but RTF 3.0.43 only ships with 2.0.7. When the newer image isn't in the customer's private registry, the mule-action container hangs silently until the Job is killed at exactly 300s — with no error surfaced in Runtime Manager.

Diagnostics

Perform Job describe output and the Job pod's container logs. Here are the exact commands to run within ~2 minutes of triggering the restart API call (before the 300s TTL garbage-collects everything). Step-by-step kubectl commands to capture the Job and pod logs within the 300s TTL window, including what to look for (ErrImagePull, DeadlineExceeded, etc.).:

1. Find the restart Job in rtf namespace (run immediately after the API call)

kubectl get jobs -n rtf

2. Describe the Job

kubectl describe job <JOB_NAME> -n rtf

# 3. Get the pod created by the Job

kubectl get pods -n rtf -l job-name=<JOB_NAME>

# 4. Get the container logs

kubectl logs <POD_NAME> -c mule-action -n rtf

# 5. Describe the pod (shows events, exit codes, pull status)

kubectl describe pod <POD_NAME> -n rtf

What we're looking for:

Job failure reason, conditions, events (e.g., DeadlineExceeded)
Whatever the mule-action container is printing — this is the key missing piece (stuck on a network call? init error? hanging on a fetch?)

Resolution

Review the restart job logs for image or dependency failures. If the logs show the restart job depends on rtf-mule-actions:2.0.20 and that image is not available in the local registry, pull the required image into the registry used by the environment and retry the POST restart API.