Repository navigation
feat(memory)!: generated agent code reads MEMORY_<NAME>_ID - #2583
Conversation
memoryEnvVarName() returns MEMORY_<NAME>_ID, the name the v0 CLI deployed, instead of AGENTCORE_MEMORY_<NAME>_ID. @aws/agentcore-cdk sets the same name as of aws/agentcore-l3-cdk-constructs#418, so the templates, the Bedrock agent import translators and export harness read the variable the deploy actually sets. BREAKING CHANGE: agent code generated by earlier v1 release candidates reads AGENTCORE_MEMORY_<NAME>_ID and must switch to MEMORY_<NAME>_ID.
|
Claude Security Review: no high-confidence findings. (run) |
There was a problem hiding this comment.
AgentCore Harness Review
Verdict: Looks good
This is a straightforward correctness fix. The memoryEnvVarName helper in src/projectSchemas/memory.ts was producing AGENTCORE_MEMORY_<NAME>_ID, but the CDK construct (AgentCoreMemory.ts:226 in agentcore-l3-cdk-constructs) actually sets MEMORY_<NAME>_ID on the runtime. That mismatch meant generated harness Python (memory/session.py) and TS (memory.ts) templates were reading an env var the deployed runtime never populated, so MEMORY_ID would be None/undefined at runtime for any agent using memory.
Verified:
- All callers (
runtime.ts,export.ts,strandsTranslator.ts,langGraphTranslator.ts) funnel through this one helper, so the single-line change covers every template. - Other parts of the CLI (
schema-mapper.ts,dev/memory-env.ts,import/actions.ts) were already using theMEMORY_<NAME>_IDconvention — this change finally makes the harness consistent with them and with the CDK. - All four impacted tests are updated.
- No stale
AGENTCORE_MEMORY_references remain (the one hit inimport/actions.tsis the unrelated legacyBEDROCK_AGENTCORE_MEMORY_IDshown in a migration message).
Nothing else needs to change before merge.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## refactor #2583 +/- ##
=========================================
Coverage 97.50% 97.50%
=========================================
Files 635 635
Lines 47250 47250
=========================================
Hits 46071 46071
Misses 1179 1179 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
nborges-aws
left a comment
There was a problem hiding this comment.
PR LGTM. Though I only see the memory prefix updated here. Based on the CDK PR we need to flip AGENTCORE_CREDENTIAL_ to CREDENTIAL_ also. Or in a follow up to this perhaps
Description
Agent code the CLI generates reads
MEMORY_<NAME>_IDfor the deployed memory id, the name the v0 CLI deployed, instead ofAGENTCORE_MEMORY_<NAME>_ID.memoryEnvVarName()is the single source of that name: the runtime templates ({{memoryEnvVarName}}inmemory/session.pyandmemory/memory.ts), the Bedrock agent import translators andexport harnessall call it, so one function changes.The matching library change is aws/agentcore-l3-cdk-constructs#418, which sets
MEMORY_<NAME>_IDon the runtime. Both sides have to agree: if the deploy sets one name and the code reads the other,os.getenvreturnsNoneand the template runs with memory off, with no error. With both changes in, v0 agent code keeps finding its memory after migration without edits, and new v1 projects read the name the deploy sets.AGENTCORE_GATEWAY_<NAME>_*) and payment (AGENTCORE_PAYMENT_*) names are the same in v0 and v1, and the CLI composes no other discovery names.@aws/agentcore-cdkbump brings the library side;refactoris unreleased, so the order does not matter.BREAKING CHANGE: agent code generated by earlier v1 release candidates reads
AGENTCORE_MEMORY_<NAME>_IDand must switch toMEMORY_<NAME>_ID.Type of Change
Testing
bun test(3975 passed)bun run typecheckbun run lint:checkbun run format:checkChecklist
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.