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
- ..
- agent_comments.rs
- authored.rs
- capture.rs
- checks.rs
- codeowners.rs
- commit_checks.rs
- compute.rs
- confidence.rs
- contributions.rs
- ghost.rs
- guardrails.rs
- inbox.rs
- labels.rs
- lib.rs
- lifecycle.rs
- memory.rs
- mentions.rs
- mergeability.rs
- messages.rs
- milestones.rs
- plans.rs
- prefetch.rs
- queue.rs
- retired.rs
- reviews.rs
- rows.rs
- rulesets.rs
- runs.rs
- settings.rs
- statuses.rs
- team_reviews.rs