hashicorp/nomad · error

unable to retrieve summary for parent job: %v

Error message

unable to retrieve summary for parent job: %v

What it means

DeleteJobTxn (nomad/state/state_store.go:1977) wraps an error from txn.First("job_summary", "id", namespace, job.ParentID) when a child (parameterized/dispatched) job is deleted and its parent's JobSummary must be adjusted. The summary lookup itself failed, aborting the deregistration transaction. This only happens for jobs with a non-empty ParentID.

Source

Thrown at nomad/state/state_store.go:1977

// DeleteJobTxn is used to deregister a job, like DeleteJob,
// but in a transaction.  Useful for when making multiple modifications atomically
func (s *StateStore) DeleteJobTxn(index uint64, namespace, jobID string, txn Txn) error {
	// Lookup the node
	existing, err := txn.First("jobs", "id", namespace, jobID)
	if err != nil {
		return fmt.Errorf("job lookup failed: %v", err)
	}
	if existing == nil {
		return fmt.Errorf("job not found")
	}

	// Check if we should update a parent job summary
	job := existing.(*structs.Job)
	if job.ParentID != "" {
		summaryRaw, err := txn.First("job_summary", "id", namespace, job.ParentID)
		if err != nil {
			return fmt.Errorf("unable to retrieve summary for parent job: %v", err)
		}

		// Only continue if the summary exists. It could not exist if the parent
		// job was removed
		if summaryRaw != nil {
			existing := summaryRaw.(*structs.JobSummary)
			pSummary := existing.Copy()
			if pSummary.Children != nil {

				modified := false
				switch job.Status {
				case structs.JobStatusPending:
					pSummary.Children.Pending--
					pSummary.Children.Dead++
					modified = true
				case structs.JobStatusRunning:
					pSummary.Children.Running--
					pSummary.Children.Dead++

View on GitHub (pinned to 482b49bf1a)

Solutions

  1. Retry the deregistration; the txn rolled back atomically
  2. Check the wrapped %v error in server logs for the root cause
  3. Ensure parent jobs and their children are GC'd together (same eval/GC cycle)
  4. Restart the server agent if the state store repeatedly errors

Example fix

// before
return s.DeleteJobTxn(idx, ns, jobID, txn)
// after
err := s.DeleteJobTxn(idx, ns, jobID, txn)
if err != nil && strings.Contains(err.Error(), "unable to retrieve summary for parent job") {
    return retryWithBackoff(func() error { return s.DeleteJobTxn(idx, ns, jobID, txn) })
}
return err
Defensive patterns

Strategy: retry

Validate before calling

// ensure parent summary is retrievable before deleting a child
if job.ParentID != "" {
    parent, err := stateStore.JobByID(nil, ns, job.ParentID)
    if err != nil { return err } // read path broken; delete would fail the same way
    _ = parent
}

Try / catch

if err := s.DeleteJobTxn(idx, ns, jobID, txn); err != nil {
    if strings.Contains(err.Error(), "unable to retrieve summary for parent job") {
        return retry(3, backoff, func() error { return s.DeleteJobTxn(idx, ns, jobID, txn) })
    }
    return err
}

Prevention

When it happens

Trigger: Deleting a dispatched/periodic child job when txn.First on the job_summary table errors (MemDB issue) — not when the parent summary is merely absent (that case is tolerated and skipped).

Common situations: Parent job already fully GC'd while children still exist; in-memory DB errors on servers applying deregistration; running many concurrent dispatch/stop operations on the same parent.

Related errors


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