You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 22c5789
Browse filesBrowse the repository at this point in the historyBrowse files
fix(trigger): do not alert on runs whose workspace was deleted mid-run
When an account deletion cascades a workspace (or its workflow) away while a
run is in flight, #9144 makes LoggingSession record the deleted scope and core
throw ExecutionScopeDeletedError when the scope is already gone at start. The
background tasks still rethrew both cases: a start-time ExecutionScopeDeletedError
is not "recorded by core", and a block that then fails (e.g. a file-upload FK
error) cannot be finalized because the log row is gone, so hasCompleted() is
false. The Trigger run FAILED and paged Slack for a workspace that no longer
exists.
workflow-execution and webhook-execution now treat a deleted scope as a quiet
outcome: when the error is ExecutionScopeDeletedError, or the session reports a
deleted scope once core's post-execution settles (or once the task's own failure
log discovers it), they log at info and complete with the #9139 failure result.
The deleted-scope check runs before the timeout rethrow: with the workspace gone
there is no owner to alert and no log to fix, and the admission slot is already
released. Live-workspace timeouts, unrecorded failures, and infra faults still
throw.
The /api/jobs projection reads the string `error` as `failed`, matching the
FAILED status these runs reported before.
schedule-execution already swallows execution errors into schedule bookkeeping
(no Trigger failure), and resume-execution has no task-level logging session,
so neither changes here.
0 commit comments