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
- ..
- 0001_init.sql
- 0002_projects.sql
- 0003_paused.sql
- 0004_redirects.sql
- 0005_domains.sql
- 0006_replaced_and_down.sql
- 0007_repo_deleted.sql
- 0008_detected.sql
- 0009_workspace_deleted.sql
- 0010_repo_deployments.sql
- 0011_workflow_builds.sql
- 0012_via_workflow.sql
- 0013_workflow_build_jobs.sql
- 0014_containers.sql
- 0015_telemetry.sql