Files
windmill/backend/migrations/20260821084723_script_insert_notify_before_lock.up.sql
T
Ruben FiszelandClaude Opus 5 3c8e4b43fd fix: resolve a script path to its new version as soon as the lock lands (#10794)
* fix: resolve a script path to its new version as soon as the lock lands

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011H5ygpzQHkPeYsjiP9GzBy

* fix: tell MCP script deploy callers to stop polling on a lock error

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011H5ygpzQHkPeYsjiP9GzBy

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-21 11:54:51 +02:00

11 lines
528 B
SQL

-- A version deployed without a lockfile gets one later from a dependency job, so gating the
-- insert notification on `lock IS NOT NULL` left the path-to-hash caches holding the previous
-- version until that UPDATE (or their TTL) came around. Notify on every insert instead: the
-- deploy itself is what makes the cached answer suspect.
DROP TRIGGER IF EXISTS script_insert_trigger ON script;
CREATE TRIGGER script_insert_trigger
AFTER INSERT ON script
FOR EACH ROW
EXECUTE FUNCTION notify_runnable_version_change('script');