hashicorp/nomad · error

could not lookup allocs: %w

Error message

could not lookup allocs: %w

What it means

While cancelling follow-up evals after a node reconnect, listing the job's allocations with AllocsByJob failed; the wrapped state read error prevents determining whether the follow-up eval can be cancelled.

Source

Thrown at nomad/state/state_store.go:4195

	return copyAlloc, nil
}

// cancelFollowupEvalsForReconnect cancels any follow-up evals for an allocation
// that was awaiting reconnect and gets an update from the client that its
// status is now known
func (s *StateStore) cancelFollowupEvalsForReconnect(txn *txn, index uint64, copyAlloc, alloc *structs.Allocation) error {

	evalID, ok := copyAlloc.FollowupEvalForReconnect(alloc)
	if !ok {
		return nil
	}

	copyAlloc.FollowupEvalID = ""

	allJobAllocs, err := s.AllocsByJob(nil, alloc.Namespace, alloc.JobID, true)
	if err != nil {
		return fmt.Errorf("could not lookup allocs: %w", err)
	}

	for _, jobAlloc := range allJobAllocs {
		if jobAlloc.ID != copyAlloc.ID && jobAlloc.FollowupEvalID == evalID && !jobAlloc.TerminalStatus() {
			// follow-up eval was created for multiple non-terminal allocs in
			// the job at the same time, so we leave it alone
			return nil
		}
	}

	raw, err := txn.First("evals", "id", evalID)
	if err != nil {
		return fmt.Errorf("followup eval lookup failed: %v", err)
	}
	if raw == nil {
		return nil // eval was deleted by user
	}
	eval := raw.(*structs.Evaluation)

View on GitHub (pinned to 482b49bf1a)

Solutions

  1. Retry the client status update that triggered reconnect handling
  2. Check server logs for state store read errors
Defensive patterns

Strategy: retry

When it happens

Trigger: Thrown at nomad/state/state_store.go:4195 when the library encounters an invalid state.

Common situations: See trigger scenarios.


AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04). Data as JSON: /api/errors/84bfb30b745c8026. Report an issue: GitHub.