From 754cae956ac8d431ddeb055453835e249cdd07b7 Mon Sep 17 00:00:00 2001 From: Ruben Fiszel Date: Thu, 25 Jun 2026 15:34:05 +0200 Subject: [PATCH] fix: use transaction for parallel_monitor_lock DELETE in last-iteration path (#9789) In the last-iteration path of a parallel for-loop (nindex == len), the DELETE FROM parallel_monitor_lock ran on the pool (db) while the transaction tx (begun earlier) was still held. This dual-connection pattern requires 2 simultaneous connections from the per-worker pool (default max 5) and can trigger "pool timed out while waiting for an open connection" under concurrent load. Run the DELETE on the held transaction (&mut *tx) instead, matching the fix PR #7861 applied to other queries in this file. The transaction is committed shortly after, so including the DELETE in it is safe and consistent with the non-last-iteration path. Fixes WIN-2099 Co-authored-by: Claude Opus 4.8 (1M context) --- backend/windmill-worker/src/worker_flow.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/backend/windmill-worker/src/worker_flow.rs b/backend/windmill-worker/src/worker_flow.rs index d378ff6be5..157f9be624 100644 --- a/backend/windmill-worker/src/worker_flow.rs +++ b/backend/windmill-worker/src/worker_flow.rs @@ -1054,7 +1054,7 @@ pub async fn update_flow_status_after_job_completion_internal( let r = sqlx::query_scalar!( "DELETE FROM parallel_monitor_lock WHERE parent_flow_id = $1 RETURNING last_ping", flow, - ).fetch_optional(db).await.map_err(|e| { + ).fetch_optional(&mut *tx).await.map_err(|e| { Error::internal_err(format!( "error while deleting parallel_monitor_lock: {e:#}" ))