aws_bedrockagentcore_memory_strategy — configuration.type fails with "Value Conversion Error" (null OverrideType)

[christopher-h-johnson]

Terraform and AWS Provider Version

Terraform v1.12.1
hashicorp/aws v6.44.0 (also reproduced on v6.43.0)

Affected Resource(s) or Data Source(s)

• aws_bedrockagentcore_memory_strategy

Expected Behavior

Setting type = "CUSTOM" with a configuration block containing type = "SEMANTIC_OVERRIDE" (or USER_PREFERENCE_OVERRIDE / SUMMARY_OVERRIDE) should create a "built-in with overrides" memory strategy, as documented in the AgentCore Memory custom strategy docs.

Actual Behavior

terraform plan fails with a "Value Conversion Error" on configuration[0].type:

Error:   : Value Conversion Error

with aws_bedrockagentcore_memory_strategy.semantic[0],
on main.tf line XX, in resource "aws_bedrockagentcore_memory_strategy" "semantic":

Cause: An unexpected error was encountered trying to build a value. This is
always an error in the provider. Please report the following to the provider
developer:

Received null value, however the target type cannot handle null values. Use
the corresponding `types` package type, a pointer type or a custom type that
handles null values.

  Path: configuration[0].type
  Target Type: types.OverrideType
  Suggested `types` Type:
    types.StringEnum[github.com/aws/aws-sdk-go-v2/service/bedrockagentcorecontrol/types.OverrideType]
  Suggested Pointer Type: *types.OverrideType

The error occurs during plan — no API call is made.

Relevant Error/Panic Output

Sample Terraform Configuration

Click to expand configuration

resource "aws_bedrockagentcore_memory_strategy" "semantic" {
  count                     = 1
  name                      = "my_semantic_facts"
  memory_id                 = aws_bedrockagentcore_memory.this.id
  memory_execution_role_arn = aws_iam_role.memory_role.arn
  type                      = "CUSTOM"
  description               = "Semantic with project-scoping override"
  namespaces                = ["facts/{actorId}/{sessionId}/"]

  configuration {
    type = "SEMANTIC_OVERRIDE"

    extraction {
      append_to_prompt = "Extract only facts specific to this project."
      model_id         = "anthropic.claude-haiku-4-5-20251001-v1:0"
    }

    consolidation {
      append_to_prompt = "Consolidate only project-specific facts."
      model_id         = "anthropic.claude-haiku-4-5-20251001-v1:0"
    }
  }
}

The same error occurs for USER_PREFERENCE_OVERRIDE and SUMMARY_OVERRIDE configuration types.

Steps to Reproduce

1. Create an aws_bedrockagentcore_memory resource
2. Create an aws_bedrockagentcore_memory_strategy with type = "CUSTOM" and a configuration block containing any valid override type string
3. Run terraform plan

Debug Logging

Click to expand log output

GenAI / LLM Assisted Development

n/a

Important Facts and References

Root Cause Analysis

Based on the error message, the provider's internal schema defines configuration.type using a non-nullable Go type (types.OverrideType — a StringEnum backed by bedrockagentcorecontrol/types.OverrideType). When Terraform's framework passes the configured string value through the schema layer, it appears to arrive as null at the point where it's converted to the target Go type.

The error message itself suggests the fix:

Suggested Pointer Type: *types.OverrideType

The field should be declared as a pointer type (*types.OverrideType) or use the types package equivalent that handles null values, so the framework can properly marshal the user-provided string into the enum.

Workaround

Use the built-in strategy types (SEMANTIC, USER_PREFERENCE, SUMMARIZATION) without a configuration block. This works but does not allow customizing extraction/consolidation prompts.

Additional Context

• The configuration block is accepted by the schema (no "unsupported block" error), confirming the provider recognizes it as a valid attribute.
• The error is purely in the provider's value conversion layer — it never reaches the AWS API.
• The AWS docs and CDK constructs both support override strategies, confirming the API supports this functionality.
• Reproduced on both v6.43.0 and v6.44.0.

Would you like to implement a fix?

No

[dosubot]

Hey @christopher-h-johnson 👋 Thank you for taking the time to raise this!

I can confirm this appears to be a provider bug in the AutoFlex expansion layer. Looking at the source code, here's what's happening:

When type = "CUSTOM" is set, the expandToCustomConfigurationInput function dispatches based on m.Type.ValueEnum() (the override type) and then calls fwflex.Expand(ctx, alias, &r.Value) to expand the customConfigurationModel into the SDK struct (e.g., CustomConfigurationInputMemberSemanticOverride.Value) [1].

The problem is that customConfigurationModel has a Type field of type fwtypes.StringEnum[awstypes.OverrideType] [2], and when AutoFlex tries to expand this into the target SDK struct's Type field (which is a non-pointer awstypes.OverrideType), the framework encounters a mismatch. The AWS SDK's CustomConfigurationInput uses a discriminated union (interface with member structs), and the individual member value structs (e.g., SemanticOverrideConfigurationInput) likely don't have a Type field at all — the type is implicit in the union member chosen. So when AutoFlex attempts to map the Type field from customConfigurationModel to a matching field in the SDK struct, it either can't find a compatible target or encounters the null conversion error you're seeing.

Your root cause analysis is essentially correct — the Type field from the Terraform model is being expanded via AutoFlex into an incompatible target. The fix likely needs to either:

1. Exclude the Type field from the auto-flex expansion (since it's already used for the switch dispatch), or
2. Change how the target type handles null/incompatible values

Your configuration itself looks correct — type = "CUSTOM" with configuration.type = "SEMANTIC_OVERRIDE" is the documented pattern, and the validation logic explicitly requires this combination [3].

For now, the workaround of using built-in strategy types without configuration is unfortunately the only path forward until this is fixed.

Written by @dosu, approved by justinretzolk

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[palazzetti]

@justinretzolk Is there any chance to get it fixed? Using "CUSTOM" type memory without the possibility to set configuration block override is very useless. Thanks for your feedback.

[anthony-effectual]

hello. any idea when a fix for this will land?

[justinretzolk]

Hey @palazzetti 👋 Thanks for checking in here! I can't speak to when this will be prioritized just yet. We base our prioritization on the count of 👍 reactions and a few other considerations (more information: prioritization guide).

[ewbankkit]

I think this error is coming from

terraform-provider-aws/internal/service/bedrockagentcore/memory_strategy.go

Lines 287 to 292 in 92b56b3

	var plannedType awstypes.OverrideType
	overrideTypePath := path.Root(names.AttrConfiguration).AtListIndex(0).AtName(names.AttrType)
	smerr.AddEnrich(ctx, &resp.Diagnostics, req.Plan.GetAttribute(ctx, overrideTypePath, &plannedType))
	if resp.Diagnostics.HasError() {
	return
	}

(at least that is where a very similar error I got whilst working on #49140 came from).
This is either fixed via #49140 or certainly in #49188 as that removes the offending PlanModifer and replaces it with RequiresReplace.