argoproj/argo-workflows · critical

%s compressed size %d > maxSize %d

Error message

%s compressed size %d > maxSize %d

What it means

When a Workflow's node status exceeds the size limit, packer compresses the Nodes field into CompressedNodes and re-checks the size; if even the compressed form exceeds maxWorkflowSize (Kubernetes etcd object limit, default ~1.5MB adjusted by env), compressWorkflow returns this error and the workflow cannot be persisted. It signals the status is fundamentally too large for the API server.

Source

Thrown at workflow/packer/packer.go:96

		return err
	}
	wf.Status.CompressedNodes = file.CompressEncodeString(ctx, string(nodeContent))
	wf.Status.Nodes = nil
	// still too large?
	large, err := IsLargeWorkflow(wf)
	if err != nil {
		wf.Status.CompressedNodes = ""
		wf.Status.Nodes = nodes
		return err
	}
	if large {
		compressedSize, err := getSize(wf)
		wf.Status.CompressedNodes = ""
		wf.Status.Nodes = nodes
		if err != nil {
			return err
		}
		return fmt.Errorf("%s compressed size %d > maxSize %d", tooLarge, compressedSize, getMaxWorkflowSize())
	}
	return nil
}

View on GitHub (pinned to 35bff19146)

Solutions

1. Reduce workflow fan-out: split into child workflows, or use artifacts/loop over chunks instead of huge withItems lists
2. Move large outputs into artifacts (S3/artifact repository) instead of inline node status
3. Ensure a database archiver (Postgres/MySQL) is configured so large node data can be offloaded rather than kept in the object
4. Check the WORKFLOW_SIZE_LIMIT / related env configuration for getMaxWorkflowSize and Kubernetes API server --max-request-size limits
5. Upgrade Argo Workflows — newer versions compress/offload node status more aggressively

Example fix

# before: giant inline fan-out
withItems: [{{ huge list of 50000 items }}]
# after: chunked child workflows
- name: chunk
  template: child
  withSequence:
    count: "10"
  arguments:
    parameters:
      - name: part
        value: "{{item}}"

// estimate node count before large fan-outs; keep well under the limit
maxNodes := 5000
if len(items) > maxNodes {
	return fmt.Errorf("fan-out of %d items will likely exceed workflow size limit; chunk it", len(items))
}

err := packer.CompressWorkflowIfNeeded(wf)
if err != nil && strings.Contains(err.Error(), "> maxSize") {
	// reduce fan-out, move outputs to artifacts, then resubmit
}

When it happens

Trigger: CompressWorkflowIfNeeded on a workflow whose node list is so large that gzip-compressed JSON still exceeds getMaxWorkflowSize() — e.g. workflows with tens of thousands of nodes or nodes carrying huge outputs/inputs.

Common situations: Fan-out workflows (withItems/withSequence over very large lists) generating enormous node graphs; steps persisting large blobs in node outputs instead of artifacts; clusters where the env-configured max size was lowered; older controller versions before automatic offloading.

Related errors

• failed to parse Workflow: %w
• [%d].name '%s' is not unique
• task result '%s' for task '%s' is invalid
• %sTried to offload but encountered error: %s
• help for metric %s is already set to %s, it cannot be change

AI-assisted analysis of argoproj/argo-workflows@35bff19146 (2026-09-03). Data as JSON: /api/errors/fa77214a6721358c. Report an issue: GitHub.