hashicorp/nomad · warning

unspecified lock operation

Error message

unspecified lock operation

What it means

getLockOperation falls through to its default case when none of the renewLock/acquireLock/releaseLock flags matched despite having passed the earlier 'at least one set' check — a defensive unreachable-in-practice branch. It returns this error to guarantee the function always returns a valid lock operation string or an explicit error rather than an empty one.

Source

Thrown at command/agent/variable_endpoint.go:309

	_, releaseLock := queryParams[releaseLockQueryParam]

	if !renewLock && !acquireLock && !releaseLock {
		return "", nil
	}

	if !isOneAndOnlyOneSet(renewLock, acquireLock, releaseLock) {
		return "", errors.New("multiple lock operations")
	}

	switch {
	case renewLock:
		return renewLockQueryParam, nil
	case acquireLock:
		return acquireLockQueryParam, nil
	case releaseLock:
		return releaseLockQueryParam, nil
	default:
		return "", errors.New("unspecified lock operation")
	}
}

View on GitHub (pinned to 482b49bf1a)

Solutions

1. No user action needed for stock Nomad; treat this as an internal invariant. Report a bug with reproduction steps if you genuinely see it.
2. If you maintain a fork, align the guard checks (renewLock/acquireLock/releaseLock conditions) with the switch cases so they cover identical conditions.
3. Audit any middleware that rewrites variable requests in-flight and could corrupt the parsed flags.
4. Pin to an official Nomad release rather than a patched build if the error appears without a clear cause.

if count == 1 {
    // exactly one op set — default case cannot be reached
}

if err := updateVariable(req); err != nil {
    if strings.Contains(err.Error(), "unspecified lock operation") {
        log.Printf("internal invariant violation in lock op parsing; report to Nomad with request dump")
        return err
    }
    return err
}

When it happens

Trigger: Only reachable if the boolean flags are in an inconsistent state relative to the earlier checks (e.g. flags mutated concurrently or the one-and-only-one check logic diverges from the switch). Normal API callers cannot hit it with well-formed requests.

Common situations: Custom forks/patches modifying getLockOperation; concurrent mutation of parsed request fields; refactoring that changes how flags are set before the switch without updating the guard checks.

Related errors

• LockNoPathErr
• multiple lock operations
• Lock delay and TTL must be positive
• TTL must be between 10 seconds and 24 hours
• ErrLockConflict

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