Files
windmill/backend/windmill-worker
Ruben FiszelandClaude Opus 4.8 754cae956a 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) <noreply@anthropic.com>
2026-06-25 13:34:05 +00:00
..

Windmill Worker

The worker. Used to process and execute flows & jobs.

This crate exposes both a library as well as a binary target.