What causes "failed to marshall cron workflow patch data: %w" in argoproj/argo-workflows?

Look at the wrapped %w cause; if none indicates json type issues, treat this as unreachable and check the Patch error instead.

argoproj/argo-workflows · warning

Internal

Internal

Error message

failed to marshall cron workflow patch data: %w

What it means

setCronWorkflowSuspend builds a JSON merge patch {"spec":{"suspend":<bool>}} with json.Marshal before patching the CronWorkflow. A marshal failure of a fixed map[string]any of a bool is practically impossible, so this Internal error almost never fires in the field; it exists as a defensive wrap. Callers are ResumeCronWorkflow and SuspendCronWorkflow.

Source

Thrown at server/cronworkflow/cron_workflow_server.go:143

	crWf, err := setCronWorkflowSuspend(ctx, false, req.Namespace, req.Name)
	if err != nil {
		return nil, sutils.ToStatusError(err, codes.Internal)
	}
	return crWf, nil
}

func (c *cronWorkflowServiceServer) SuspendCronWorkflow(ctx context.Context, req *cronworkflowpkg.CronWorkflowSuspendRequest) (*v1alpha1.CronWorkflow, error) {
	crWf, err := setCronWorkflowSuspend(ctx, true, req.Namespace, req.Name)
	if err != nil {
		return nil, sutils.ToStatusError(err, codes.Internal)
	}
	return crWf, nil
}

func setCronWorkflowSuspend(ctx context.Context, setTo bool, namespace, name string) (*v1alpha1.CronWorkflow, error) {
	data, err := json.Marshal(map[string]any{"spec": map[string]any{"suspend": setTo}})
	if err != nil {
		return nil, sutils.ToStatusError(fmt.Errorf("failed to marshall cron workflow patch data: %w", err), codes.Internal)
	}
	cronWfs, err := auth.GetWfClient(ctx).ArgoprojV1alpha1().CronWorkflows(namespace).Patch(ctx, name, types.MergePatchType, data, metav1.PatchOptions{})
	if err != nil {
		return nil, sutils.ToStatusError(err, codes.Internal)
	}
	return cronWfs, nil
}

func (c *cronWorkflowServiceServer) getCronWorkflowAndValidate(ctx context.Context, namespace string, name string, options metav1.GetOptions) (*v1alpha1.CronWorkflow, error) {
	wfClient := auth.GetWfClient(ctx)
	cronWf, err := wfClient.ArgoprojV1alpha1().CronWorkflows(namespace).Get(ctx, name, options)
	if err != nil {
		return nil, sutils.ToStatusError(err, codes.Internal)
	}
	err = c.instanceIDService.Validate(cronWf)
	if err != nil {
		return nil, sutils.ToStatusError(err, codes.InvalidArgument)
	}

View on GitHub (pinned to 35bff19146)

Solutions

Look at the wrapped %w cause; if none indicates json type issues, treat this as unreachable and check the Patch error instead.
If you genuinely hit it after modifying the code to include unmarshalable values in the patch map, fix the map contents (e.g. channels/funcs).
For suspend/resume problems, verify the CronWorkflow exists and argo-server RBAC allows `patch cronworkflows`.
Use `argo cron resume`/`suspend <name>` which route through this helper and surface the real underlying error.
Retry the call — transient API-server errors on Patch return the adjacent codes.Internal wrap.

Defensive patterns

Strategy: try-catch

Try / catch

cronWf, err := client.SuspendCronWorkflow(ctx, &cronworkflowpkg.SuspendCronWorkflowRequest{Namespace: ns, Name: name})
if err != nil {
	if strings.Contains(err.Error(), "failed to marshall cron workflow patch data") {
		// practically unreachable; report bug with wrapped cause
	}
	// more likely: handle Patch errors (NotFound/Forbidden) separately
}

Prevention

Treat this as a defensive branch; investigate the wrapped inner error first
Distinguish from the adjacent Patch error which is the realistic failure
Keep the patch map limited to marshalable simple values if modifying code
Retry transient Internal errors once before failing

When it happens

Trigger: Theoretically only if json.Marshal fails on the literal map — not reachable with current inputs (bool values only). Seen in code paths where Suspend/Resume are invoked and the error surfaced from an unrelated patched-object failure being conflated.

Common situations: Reading this in logs usually means you are looking at the sibling error on the next line (the Patch call, also wrapped with codes.Internal) rather than the marshal itself.

Understand the failure class

Background: json.Marshal / "failed to marshal" errors in Go: why "unsupported type" happens and how to fix it — this error's family across 22 libraries.

Related errors

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