Stata batch workers ↔ Kubernetes rolling update: can code changes be picked up without restart?

Answer

No. A Stata batch worker reads the .do file only when the process starts. Changing the file on disk does not cause a running Stata instance to reload the script, so code updates are only seen by newly started workers.

Confirmed facts

• Stata’s batch mode (stata -b file.do) loads the script once at process start; there is no internal reload or hot‑swap mechanism.
• During a Kubernetes rolling update, pods that are created after the .do file has been updated will execute the new version, while existing pods continue to run the version they loaded at launch.
• Readiness probes can prevent traffic from reaching a pod until its startup script finishes, but they cannot force an already‑running pod to reload its script.

Steps needed for this case

1. Update the .do file in the source that pods mount (e.g., a ConfigMap or a new container image).
2. Trigger a rolling update (e.g., kubectl rollout restart deployment/stata-workers).
3. Ensure the pod’s readiness probe waits for the Stata process to start and signal readiness (e.g., a small wrapper script that exits only after Stata is ready).
4. If jobs are dispatched via a queue, drain the old pods before they are terminated so that no in‑flight job runs on the old version after new pods are available. This can be done with a preStop hook or by scaling the old replica set to zero after the new replicas are ready.
5. Monitor logs or a version‑stamp written by the do‑file to confirm that new jobs see the updated code and that old jobs finish with the previous version.

Missing diagnostic detail

Are incoming jobs placed on a durable queue that allows the old workers to be drained, or are they handled synchronously by the pod that receives the request? If jobs are synchronous, you must coordinate a brief cut‑over or use a sidecar that signals workers to finish current work before terminating; otherwise a window of mixed‑version execution may occur.

Verification

1. Deploy a test pod with a do‑file that writes a version string to a log file; run a job and verify the logged version.
2. Replace the do‑file with a new version, roll out the update, and run a new job to confirm the new version appears in the log.
3. During the rollout, check that the readiness probe blocks traffic to pods until they report ready, and that no new jobs are routed to pods still reporting the old version.