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
- Upgrade Terraform Core to a release that knows how to persist the mark (or that stops emitting it into state).
- Upgrade the provider whose SDK introduced the unsupported mark.
- Report the bug to hashicorp/terraform with the state file and provider versions; the message itself flags it as a Terraform bug.
- 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
- Only ever write marks.Sensitive or marks.Deprecation into values destined for state.
- When adding a new cty mark type, update unmarkValueForMarshaling's allowlist first.
- Upgrade Terraform Core and providers together so mark sets stay in sync.
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
- Unsupported path step %#v (%t)
- resource %s has an unsupported mode %s
- resource %s has an unsupported mode %s
- preparing attribute values for %s: %w
- preparing identity values for %s: %w
AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07).
Data as JSON: /api/errors/d54241dbd0fd1837.
Report an issue: GitHub.