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
- ..
- agents
- chat
- customize
- folios
- people
- team
- actions-settings.tsx
- agents.tsx
- apps.tsx
- audit-export.ts
- audit.tsx
- billing.tsx
- chat-settings.tsx
- code-access.tsx
- code-overview.tsx
- context.tsx
- emoji.tsx
- gateway.tsx
- guardrails.tsx
- home-seen.ts
- home.tsx
- integrations-directory.tsx
- integrations.tsx
- layout.tsx
- member-invitations.tsx
- members.tsx
- memory.tsx
- moved.ts
- new.tsx
- overview.tsx
- package.tsx
- packages.tsx
- people.tsx
- permissions.tsx
- personal-access-tokens.tsx
- pins.ts
- projects.tsx
- repositories.tsx
- rules.tsx
- ruleset.tsx
- runners.tsx
- secrets.tsx
- security-bypass.tsx
- security-patterns.tsx
- security-settings.tsx
- security.tsx
- settings.tsx
- soon.tsx
- spend-pill.ts
- spend-receipt.tsx
- spend.tsx
- statement-csv.ts
- statement-entries.ts
- tab-soon.tsx
- team-new.tsx
- teams.tsx
- token-new.tsx
- token.tsx
- tokens.tsx
- usage.tsx
- webhooks.tsx
- workspace-overview.tsx