syntaqxA job that runs again is no longer stopped by the time cap of the attempt before it. A sandbox's Durable Object is named for its work (actions:{job} for a workflow job), and a re-run keeps the job's id, so every attempt of a job runs in the same object; each attempt scheduled its time cap's alarm there and none cleared it. The Desktop release's Linux job showed it: attempt 1 started at 12:47:17 with a 60-minute cap, so its alarm fired at 13:50:17, four minutes into attempt 3, and stopped attempt 3's build mid-compile (its log's last line is at 13:50:17). Now a sandbox clears the alarm, the cap and the stop reason an earlier attempt left when it starts, and the alarm stops a run only once that run has used its own whole cap, so alarms already scheduled before this deploy cannot do it either.89d501cHistory
- ..
- anchors.yml
- artifacts.yml
- branches-ignore.yml
- cache.yml
- codeql.yml
- concurrency.yml
- container-job.yml
- defaults.yml
- dependabot-automerge.yml
- description-and-env.yml
- docker-action.yml
- docker-publish.yml
- environments.yml
- g1t-extension.yml
- go.yml
- if-expressions.yml
- issue-comment.yml
- java-gradle.yml
- job-options.yml
- labeler.yml
- many-events.yml
- matrix-from-json.yml
- max-parallel-expression.yml
- merge-queue.yml
- multiline-and-quotes.yml
- needs-outputs.yml
- node-matrix.yml
- on-null-events.yml
- pages.yml
- permissions-all.yml
- pr-review.yml
- pr-target-paths.yml
- publish-npm.yml
- python-package.yml
- release-on-tag.yml
- repository-dispatch.yml
- reusable-called.yml
- reusable-caller.yml
- runs-on-forms.yml
- rust-ci.yml
- sccache-like.yml
- schedule.yml
- services-postgres.yml
- single-event-string.yml
- stale.yml
- step-options.yml
- workflow-call-and-dispatch.yml
- workflow-dispatch-inputs.yml
- workflow-run.yml