docker/cli · error

failed to get tasks

Error message

failed to get tasks: %w

What it means

Thrown by waitOnTasks while polling swarm tasks during 'docker stack rm'. The loop calls getStackTasks(ctx, apiClient, namespace) and wraps any non-nil error from the daemon task-list API. It surfaces transport, auth, or swarm-state failures encountered while waiting for a stack's tasks to reach a terminal state.

Solutions

  1. Check 'docker node ls' and 'docker info' to confirm the targeted manager is reachable and healthy.
  2. Re-run 'docker stack rm <stack>' once the swarm recovers quorum / the daemon is back up.
  3. If the wait loop itself is the problem, verify DOCKER_HOST / context and daemon connectivity with 'docker version'.
  4. Inspect underlying cause by running with DOCKER_DEBUG=1 / 'docker --debug stack rm' to see the wrapped error.

Example fix

// before: removal may hang/fail if the manager is temporarily unreachable
docker stack rm mystack

// after: target a known-good manager and confirm quorum first
docker node ls
docker context use manager-prod
docker stack rm mystack
Defensive patterns

Strategy: try-catch

Validate before calling

// Before stacking removal, confirm manager reachability
if err := pingManager(ctx, apiClient); err != nil {
    return fmt.Errorf("swarm manager unreachable before stack rm: %w", err)
}

Type guard

func isTaskListErr(err error) bool {
	return err != nil && strings.Contains(err.Error(), "failed to get tasks:")
}

Try / catch

err := waitOnTasks(ctx, client, ns)
if err != nil {
    // non-fatal: stack may still be removed; retry or surface to user
    return fmt.Errorf("stack removal polling failed: %w", err)
}

Prevention

When it happens

Trigger: Running 'docker stack rm <stack>' against a manager that cannot list tasks (network drop, node lost quorum, task-list API error, or the swarm was partially torn down while waiting). Any failure inside getStackTasks propagates as 'failed to get tasks: <underlying>'.

Common situations: Manager left the swarm or lost quorum mid-removal; DOCKER_HOST points at an unhealthy daemon; TLS/MTLS misconfiguration between CLI and manager; large stacks where the wait loop races the daemon shutting down services.

Related errors


AI-assisted analysis of docker/cli@4f84911bfe (2026-08-07). Data as JSON: /api/errors/5bb4bbc6f686be1e. Report an issue: GitHub.

Appendix: source

Thrown at cli/command/stack/remove.go:179

	swarm.TaskStateReady:     7,
	swarm.TaskStateStarting:  8,
	swarm.TaskStateRunning:   9,
	swarm.TaskStateComplete:  10,
	swarm.TaskStateShutdown:  11,
	swarm.TaskStateFailed:    12,
	swarm.TaskStateRejected:  13,
}

func terminalState(state swarm.TaskState) bool {
	return numberedStates[state] > numberedStates[swarm.TaskStateRunning]
}

func waitOnTasks(ctx context.Context, apiClient client.APIClient, namespace string) error {
	terminalStatesReached := 0
	for {
		res, err := getStackTasks(ctx, apiClient, namespace)
		if err != nil {
			return fmt.Errorf("failed to get tasks: %w", err)
		}

		for _, task := range res.Items {
			if terminalState(task.Status.State) {
				terminalStatesReached++
				break
			}
		}

		if terminalStatesReached == len(res.Items) {
			break
		}
	}
	return nil
}

View on GitHub (pinned to 4f84911bfe)