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
- ..
- apache_airflow.yml
- argoproj_argo-cd.yml
- aws_aws-cdk.yml
- cli_cli.yml
- cloudflare_workers-sdk.yml
- dependabot_dependabot-core.yml
- docker_compose.yml
- electron_electron.yml
- every-option.yml
- getsentry_sentry.yml
- github_docs.yml
- hashicorp_terraform.yml
- hashicorp_vault.yml
- huggingface_transformers.yml
- microsoft_TypeScript.yml
- microsoft_vscode.yml
- nodejs_node.yml
- pypa_pip.yml
- python_cpython.yml
- pytorch_pytorch.yml
- supabase_supabase.yml
- tokio-rs_tokio.yml