What causes "interrupted - last error: %v" in hashicorp/terraform?

If the interrupt was intentional, no fix is needed — this is expected behavior on cancellation.

interrupted - last error: %v

Error message

interrupted - last error: %v

What it means

communicator.Retry at communicator.go:89 runs function f with exponential backoff until it succeeds, returns a Fatal error, or the context ends. If the context was canceled (context.Canceled) the select at communicator.go:163 returns this with the last retryable error attached. This represents an interruption — typically user-initiated (Ctrl-C).

Source

Thrown at internal/communicator/communicator.go:164

		}
	}()

	// Wait for completion
	select {
	case <-ctx.Done():
	case <-doneCh:
	}

	var lastErr error
	// Check if we got an error executing
	if ev, ok := errVal.Load().(errWrap); ok {
		lastErr = ev.E
	}

	// Check if we have a context error to check if we're interrupted or timeout
	switch ctx.Err() {
	case context.Canceled:
		return fmt.Errorf("interrupted - last error: %v", lastErr)
	case context.DeadlineExceeded:
		return fmt.Errorf("timeout - last error: %v", lastErr)
	}

	if lastErr != nil {
		return lastErr
	}
	return nil
}

View on GitHub (pinned to c9def3e214)

Solutions

If the interrupt was intentional, no fix is needed — this is expected behavior on cancellation.
If unexpected, find what is canceling the context (parent process, signal handler, timeout wrapper).
Make the remote target more reliable so fewer retries are needed before an intentional cancel.

Example fix

// before — Ctrl-C during provisioner
^C
Error: interrupted - last error: dial tcp 10.0.0.5:22: connect: connection refused

// after — no code fix; this is the expected result of cancellation. To avoid accidental cancels, run non-interactively:
$ terraform apply -auto-approve

Defensive patterns

Strategy: try-catch

Validate before calling

null

Type guard

null

Try / catch

err := communicator.Retry(ctx, func() error { return c.Connect(o) })
if err != nil && errors.Is(ctx.Err(), context.Canceled) {
    // graceful: the run was interrupted; log and exit cleanly
    return nil
}

Prevention

Only cancel the retry context when you genuinely intend to abort.
Propagate cancellation cleanly so users see 'interrupted' rather than a hung process.
Log the last error so the cause of the failed retries is not lost.

When it happens

Trigger: The retry context is canceled mid-backoff — the user pressed Ctrl-C, a parent context was canceled, or the provisioner was torn down.

Common situations: User interrupted a long-running provisioner; test harness canceled the context; orchestration aborted the apply.

Related errors

AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07). Data as JSON: /api/errors/a11ff432e51cade4. Report an issue: GitHub.