You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In AWS Batch, jobs are sent to a job queue before running. The job queue only allows certain instance sizes. This is specified in the associated compute environment (CE), and often not configured by the user, but instead someone who has set up the Batch runtime for them to use (following docs).
Problem
Jobs that request resources beyond the limits of the largest instance size available for the compute environment will be stuck as RUNNABLE indefinitely. This is documented behavior by AWS Batch.
The problem is that it's not clear to users why the job is stuck as RUNNABLE, and what can be done to address it.
Possible solutions
Nextstrain CLI: Detect when a job requests resources beyond the limits of the largest instance size available for the compute environment and exit with an error instead of submitting the job.
This would be the best user experience, but I'm not sure about feasibility. At the very least, users will need additional permissions to batch:DescribeComputeEnvironments and/or ec2:DescribeInstanceTypes. Job queues / compute environments can also be set up in a way where it is difficult to infer limits of the largest instance size.
Nextstrain CLI: Detect when a job is stuck in RUNNABLE and display a warning message or automatically cancel.
This only applies if the user is attached to the job.
Job queue config: set jobStateTimeLimitActions to automatically cancel a job stuck as RUNNABLE due to requesting resources beyond CE limits.
This relies on external configuration. Should be added to AWS Batch setup docs.
While a technological solution like (1) would be nice (I've run into this before!), I think writing a docs page summarising the causes and how to troubleshoot is good enough if it's flagged up by the CLI when (a) re-attatching to a job which is runnable and was submitted over an hour ago or (b) when the CLI is attached and the job's been runnable for more than an hour.
Looks like there's a jobStateTimeLimitActions parameter that we can set to automatically cancel jobs stuck in the RUNNABLE state. I wonder if we can then surface the statusReason for the automatically cancelled job to the user when they reattach?
@joverlee521 nice, I've added that as solution 3. Nextstrain CLI already surfaces statusReason for completed jobs:
Job now SUBMITTED
Job now RUNNABLE
Job FAILED after 10.2 minutes (Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT)
Note that it's an external solution and the minimum is 10 minutes.
Solution 2 can still be used to immediately cancel any stuck jobs if the user is attached, regardless of whether their job queue has been configured with jobStateTimeLimitActions.
Activity
jameshadfield commentedon Oct 8, 2026
While a technological solution like (1) would be nice (I've run into this before!), I think writing a docs page summarising the causes and how to troubleshoot is good enough if it's flagged up by the CLI when (a) re-attatching to a job which is runnable and was submitted over an hour ago or (b) when the CLI is attached and the job's been runnable for more than an hour.
joverlee521 commentedon Oct 8, 2026
Looks like there's a jobStateTimeLimitActions parameter that we can set to automatically cancel jobs stuck in the RUNNABLE state. I wonder if we can then surface the
statusReasonfor the automatically cancelled job to the user when they reattach?victorlin commentedon Oct 9, 2026
@joverlee521 nice, I've added that as solution 3. Nextstrain CLI already surfaces
statusReasonfor completed jobs:Note that it's an external solution and the minimum is 10 minutes.
Solution 2 can still be used to immediately cancel any stuck jobs if the user is attached, regardless of whether their job queue has been configured with
jobStateTimeLimitActions.