fix(memory): pass boto3 session to MemoryClient in AgentCoreMemorySessionManager

[avneetbansal-aws]

Fixes #681.

Problem

`AgentCoreMemorySessionManager.init` constructed its `MemoryClient` without a boto3 session:
```python
self.memory_client = MemoryClient(region_name=region_name) # no session
session = boto_session or boto3.Session(region_name=region_name)
```
Because no session is passed, `MemoryClient.init` builds its `gmcp_client`/`gmdp_client` from a default `boto3.Session()` — so a user-provided `boto_session` (named profile, custom credentials, etc.) is silently discarded on the `MemoryClient` itself. The manager then overwrites those two clients from the correct session, but the `MemoryClient` was still initialized against the wrong one.

Fix

Resolve the session first, then pass it into `MemoryClient`, which already accepts `boto3_session`:
```python
session = boto_session or boto3.Session(region_name=region_name)
self.memory_client = MemoryClient(region_name=region_name, boto3_session=session)
```
The existing `strands-agents` user-agent / `boto_client_config` override that follows is unchanged, so behavior for the overridden clients is identical — the fix just ensures the `MemoryClient` uses the correct session from the start.

Tests

• Updated `test_init_basic` to assert `MemoryClient` receives `boto3_session`.
• Added `test_init_passes_boto_session_to_memory_client` asserting a user-provided `boto_session` reaches `MemoryClient`.
• Full `test_agentcore_memory_session_manager.py` suite passes (189 tests); ruff lint + format clean.

[kimnamu]

Thanks for turning #681 into a one-line fix and adding a test that pins the session hand-off.

I replayed this commit onto current main (99663b0, v1.24.1) and it applies cleanly. The CI/CD Pipeline run on this fork PR is still action_required, so here are local results on Python 3.10, plus the real constructor timed before and after:

Check	main 99663b0	this PR on main
test_init_basic + test_init_passes_boto_session_to_memory_client	2 failed	2 passed
Constructor with a long-lived boto_session (median of 20, 4 runs)	147–186 ms	12.0–12.3 ms
Constructor with region_name only (same)	295–330 ms	113–117 ms
memory_client.region_name when boto_session is in eu-west-1	us-west-2	eu-west-1
read_timeout=11 from boto_client_config on gmcp_client / gmdp_client	11 / 11	11 / 11

The last two rows are the side points in #681. The region attribute and the Initialized MemoryClient log line now agree with the clients that serve calls. boto_client_config already reached those clients on main through the overrides at session_manager.py:195-200. Only the two clients MemoryClient builds and then drops ignore it, and with this change they come from the overrides' session. Unless I'm missing a code path, Fixes #681 covers the whole issue. It also matches memorystore/store.py:62, which already passes boto3_session=session to MemoryClient.

# main 99663b0, this PR's tests kept, source line reverted
$ uv run pytest tests/bedrock_agentcore/memory/integrations/strands/test_agentcore_memory_session_manager.py -q -k "test_init_basic or test_init_passes_boto_session_to_memory_client"
E           Expected: MemoryClient(region_name=None, boto3_session=<Mock name='Session()' id='4619555296'>)
E           Actual: MemoryClient(region_name=None)
2 failed, 188 deselected, 2 warnings in 0.90s
$ uv run python repro.py
bedrock_agentcore.memory.client: Initialized MemoryClient for control plane: us-west-2, data plane: us-west-2
memory_client.region_name = us-west-2
gmcp_client: region=eu-west-1 read_timeout=11
gmdp_client: region=eu-west-1 read_timeout=11
ctor, long-lived boto_session:  186.1 ms
ctor, region_name only:         311.3 ms

# this PR (e9d18ab) replayed on main
$ uv run pytest tests/bedrock_agentcore/memory/integrations/strands/test_agentcore_memory_session_manager.py -q -k "test_init_basic or test_init_passes_boto_session_to_memory_client"
2 passed, 188 deselected, 2 warnings in 0.58s
$ uv run python repro.py
bedrock_agentcore.memory.client: Initialized MemoryClient for control plane: eu-west-1, data plane: eu-west-1
memory_client.region_name = eu-west-1
gmcp_client: region=eu-west-1 read_timeout=11
gmdp_client: region=eu-west-1 read_timeout=11
ctor, long-lived boto_session:   12.2 ms
ctor, region_name only:         116.5 ms
$ uv run pytest tests/bedrock_agentcore/memory -q
782 passed, 23 warnings in 42.16s
$ uv run ruff check src tests && uv run ruff format --check src tests
All checks passed!
277 files already formatted

repro.py (real constructor, no network)

Only RepositorySessionManager.__init__ is patched, as in this PR's tests, so read_session never goes out. The dummy keys just keep botocore from looking for real credentials.

# Real AgentCoreMemorySessionManager constructor. Only RepositorySessionManager.__init__
# (the read_session network call) is patched, the same way the PR's tests do it.
import logging, os, statistics, time
from unittest.mock import patch

for k in ("AWS_PROFILE", "AWS_REGION", "AWS_DEFAULT_REGION"):
    os.environ.pop(k, None)
os.environ.update(AWS_CONFIG_FILE="/dev/null", AWS_SHARED_CREDENTIALS_FILE="/dev/null",
                  AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE",
                  AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
                  AWS_EC2_METADATA_DISABLED="true")

import boto3
from botocore.config import Config
from bedrock_agentcore.memory.integrations.strands.config import AgentCoreMemoryConfig
from bedrock_agentcore.memory.integrations.strands.session_manager import AgentCoreMemorySessionManager

logging.basicConfig(format="%(name)s: %(message)s")
log = logging.getLogger("bedrock_agentcore.memory.client")
cfg = AgentCoreMemoryConfig(memory_id="mem-123", session_id="s-1", actor_id="a-1")


def build(**kw):
    with patch("strands.session.repository_session_manager.RepositorySessionManager.__init__", return_value=None):
        return AgentCoreMemorySessionManager(cfg, **kw)


log.setLevel(logging.INFO)
m = build(boto_session=boto3.Session(region_name="eu-west-1"), boto_client_config=Config(read_timeout=11))
log.setLevel(logging.WARNING)
print("memory_client.region_name =", m.memory_client.region_name)
for name in ("gmcp_client", "gmdp_client"):
    c = getattr(m.memory_client, name)
    print(f"{name}: region={c.meta.region_name} read_timeout={c.meta.config.read_timeout}")


def median_ms(fn, n=20):
    fn()
    xs = []
    for _ in range(n):
        t0 = time.perf_counter()
        fn()
        xs.append((time.perf_counter() - t0) * 1000)
    return statistics.median(xs)


warm = boto3.Session(region_name="us-west-2")
print(f"ctor, long-lived boto_session: {median_ms(lambda: build(boto_session=warm)):6.1f} ms")
print(f"ctor, region_name only:        {median_ms(lambda: build(region_name='us-west-2')):6.1f} ms")

[avneetbansal-aws]

Thanks @kimnamu for replaying the commit and validating it so thoroughly — the before/after tests, the constructor benchmarks, and the full-suite + lint run are all appreciated.

Your reading matches mine. The two clients MemoryClient constructs internally (gmcp_client / gmdp_client) were the only path still ignoring the overrides' session, so routing them through boto3_session is what brings region_name, the Initialized MemoryClient log line, and boto_client_config into agreement with the clients that actually serve calls. It also lines up with memorystore/store.py:62, which already passes boto3_session=session. I don't think there's another code path left, so Fixes #681 should cover the whole issue.

The CI run still showing action_required is just the fork-PR workflow-approval gate rather than anything in the diff — happy to rerun locally against any other scenario if that's useful while it waits on approval.

[avneetbansal-aws]

Thanks again @kimnamu for replaying the commit and validating it. Is there anything further you need from me to move this forward, or is it just waiting on a maintainer approval/merge at this point? Happy to rebase onto current main if that helps.

[kimnamu]

Thanks for following up, and for offering to rebase.

Nothing is needed from me. I don't have write access here, so my earlier comment was only an independent local check. As far as I can tell the PR is waiting on maintainer approvals, and a rebase isn't needed:

Checked today	Result
main vs. the sha I replayed on	still 99663b0 (GitHub compare: identical)
e9d18ab merged with main locally	no conflicts; the diff against main is only this PR's 2 files
Rulesets on main	1 approving review from a required reviewer team; no required status checks, so the branch doesn't have to be up to date
Workflow runs on e9d18ab	CI/CD Pipeline and 5 other runs at action_required; Secure Integration test waiting on the manual-approval environment (9 test jobs)
Full unit suite on the merge, Python 3.10	3594 passed, 10 skipped, 4 xpassed; coverage 91.11% (90% required)

If a rebase does come up later, the default-branch ruleset has dismiss_stale_reviews_on_push enabled, so a push after an approval would dismiss it.

# e9d18ab merged with main 99663b0, local only
$ uv run pytest tests/bedrock_agentcore/memory/integrations/strands/test_agentcore_memory_session_manager.py -q
190 passed, 2 warnings in 5.34s
$ uv run pytest tests/bedrock_agentcore/memory -q
782 passed, 23 warnings in 74.40s (0:01:14)
$ uv run pytest tests/ --cov=src --cov-precision=2 -q
Required test coverage of 90.0% reached. Total coverage: 91.11%
3594 passed, 10 skipped, 4 xpassed, 143 warnings in 146.12s (0:02:26)
$ uv run ruff check src tests && uv run ruff format --check src tests
All checks passed!
277 files already formatted

[avneetbansal-aws]

Thanks @kimnamu, that's clear and helpful. Good to have the rebase question settled too, the compare showing main still at 99663b0 and the clean local merge of e9d18ab match what I see, so I'll hold off on pushing anything that would trip dismiss_stale_reviews_on_push.

Sounds like it's purely waiting on a maintainer approval and the workflow-approval gate at this point. I'll leave the branch as-is so the existing review stays intact. Happy to rebase or rerun any scenario the moment a maintainer needs it.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@c7423e5). Learn more about missing BASE report.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #682   +/-   ##
=======================================
  Coverage        ?   89.58%           
=======================================
  Files           ?      124           
  Lines           ?    10687           
  Branches        ?     1670           
=======================================
  Hits            ?     9574           
  Misses          ?      728           
  Partials        ?      385           

Flag	Coverage Δ
unittests	89.58% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[avneetbansal-aws]

Thank you @jariy17 for approving. Local unit tests and lint pass. The 10 red checks are the pull_request_target fork-checkout refusal in the Secure Integration / Breaking Change workflows, not anything in the diff. Is there a maintainer who can approve the workflow run or merge when convenient?

[jariy17]

Thanks @kimnamu, this is a really thorough verification, and the constructor timing is a nice bonus I hadn't expected from a one-line change.

The red checks aren't from this change: the Secure Integration jobs refuse to check out fork PR code under pull_request_target, and the Breaking Change Check analysis passes but can't post its comment from a fork. I ran both locally, along with the memory integration tests, and they pass.

Merging this now; it'll be available in the next release.