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
- ..
- backup.test.ts
- backup.ts
- broker-egress.ts
- broker.test.ts
- broker.ts
- bump.test.ts
- bump.ts
- computer-shape.ts
- computer.test.ts
- computer.ts
- credentials.test.ts
- credentials.ts
- delegate.test.ts
- delegate.ts
- egress.test.ts
- egress.ts
- forward.test.ts
- forward.ts
- gate.test.ts
- guard.ts
- hosted.test.ts
- hosted.ts
- hub.ts
- index.ts
- instructions.test.ts
- instructions.ts
- lifecycle.test.ts
- lifecycle.ts
- mentions.test.ts
- mentions.ts
- model-defaults.test.ts
- model-env.test.ts
- model-env.ts
- repo-instructions.ts
- self-hosted.test.ts
- self-hosted.ts
- workflow-hosts.test.ts