hashicorp/terraform · error

%s: cannot serialize value marked as %#v for inclusion in a

Error message

%s: cannot serialize value marked as %#v for inclusion in a state snapshot (this is a bug in Terraform)

What it means

Thrown by unmarkValueForMarshaling when a cty value in state carries a mark other than the two that Terraform knows how to persist (marks.Sensitive and marks.Deprecation). The message explicitly states this is a bug in Terraform: only those two marks are serializable, and any other mark indicates an internal subsystem wrote a non-persistable mark into state.

Source

Thrown at internal/command/jsonstate/state.go:624

		panic(fmt.Sprintf("sensitiveAsBool cannot handle %#v", val))
	}
}

// unmarkValueForMarshaling takes a value that possibly contains marked values
// and returns an equal value without markings along with the separated mark
// metadata that should be presented alongside the value in another JSON
// property.
//
// This function only accepts the marks that are valid to persist, and so will
// return an error if other marks are present. Marks that this package doesn't
// know how to store must be dealt with somehow by a caller -- presumably by
// replacing each marked value with some sort of storage placeholder.
func unmarkValueForMarshaling(v cty.Value) (unmarkedV cty.Value, sensitivePaths []cty.Path, err error) {
	val, pvms := v.UnmarkDeepWithPaths()
	sensitivePaths, otherMarks := marks.PathsWithMark(pvms, marks.Sensitive)
	_, otherMarks = marks.PathsWithMark(otherMarks, marks.Deprecation)
	if len(otherMarks) != 0 {
		return cty.NilVal, nil, fmt.Errorf(
			"%s: cannot serialize value marked as %#v for inclusion in a state snapshot (this is a bug in Terraform)",
			tfdiags.FormatCtyPath(otherMarks[0].Path), otherMarks[0].Marks,
		)
	}
	return val, sensitivePaths, err
}

View on GitHub (pinned to c9def3e214)

Solutions

  1. Upgrade Terraform Core to a release that knows how to persist the mark (or that stops emitting it into state).
  2. Upgrade the provider whose SDK introduced the unsupported mark.
  3. Report the bug to hashicorp/terraform with the state file and provider versions; the message itself flags it as a Terraform bug.
  4. Workaround: re-apply the affected resource so a fresh value without the rogue mark is written to state.
Defensive patterns

Strategy: try-catch

Validate before calling

// Before marshaling, assert no value carries marks outside the persistable set.
_, _, other := marksPersistable(v)
if len(other) != 0 {
    return fmt.Errorf("internal bug: value has non-persistable mark %#v", other[0].Marks)
}

Try / catch

if _, _, err := jsonstate.UnmarkValueForMarshaling(v); err != nil {
    // Explicit Terraform bug — report upstream and re-apply the resource to clear the rogue mark.
    return err
}

Prevention

When it happens

Trigger: Raised when, after unmarking, marks.PathsWithMark finds remaining marks that are neither Sensitive nor Deprecation. The first offending path and mark set are reported. Surfaced indirectly via the 'preparing attribute values' wrappers (628/630) during JSON state rendering.

Common situations: Almost always an internal Terraform/provider bug — a subsystem introduced a new cty mark (e.g. for ephemeral values, ephemeral-as-mark, or a custom provider mark) that the state serializer cannot handle. Seen in prerelease builds or when a provider SDK adds a mark type Terraform Core does not yet whitelist for persistence.

Related errors


AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07). Data as JSON: /api/errors/d54241dbd0fd1837. Report an issue: GitHub.