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_text_ids.sql
- 0003_unique_email.sql
- 0004_email_verification.sql
- 0005_token_expiry.sql
- 0006_device_codes.sql
- 0007_rfc3339_timestamps.sql
- 0008_workspaces.sql
- 0009_oauth.sql
- 0010_workspace_tokens.sql
- 0011_agent_tokens.sql
- 0012_avatars.sql
- 0013_profiles.sql
- 0014_workspace_redirects.sql
- 0015_run_credentials.sql
- 0016_deleted_workspaces.sql
- 0017_github.sql
- 0018_invites.sql
- 0019_user_emails.sql
- 0020_access.sql
- 0021_waitlist_notices.sql
- 0022_token_scopes.sql
- 0023_retire_token_reach.sql
- 0024_g1t_name.sql
- 0025_workspace_soft_delete.sql
- 0026_workspace_residency.sql
- 0027_teams.sql
- 0028_team_creation.sql
- 0029_workspace_aliases.sql
- 0030_job_tokens.sql
- 0031_membership.sql
- 0032_two_factor.sql
- 0033_identity_jobs.sql
- 0034_fine_grained_tokens.sql
- 0035_deploy_keys.sql
- 0036_email_confirmation_codes.sql
- 0037_account_deletion.sql
- 0038_shared_invites.sql
- 0039_profile_timezone.sql
- 0040_workspace_invitations.sql
- 0041_one_kind_of_token.sql
- 0042_username_case.sql
- 0043_website_tokens.sql
- 0044_dock_pins.sql
- 0045_people_and_teams.sql
- 0046_sound_settings.sql