Context

Describe the background behind the problem.

scripts/start_local_atlas.sh starts the local Atlas container with docker run -P (random host port mapping), then writes the real connection string to .local_atlas_uri at the repo root. Every package's justfile sets dotenv-load + dotenv-filename := "../../.local_atlas_uri", so any just [recipe] invocation picks up the correct dynamic MONGODB_URI. But just's dotenv loading only applies inside just's own process — it is never exported to the parent GitHub Actions shell.

The "Run unit tests with minimum dependency versions" step in both .github/workflows/test.yml and .github/workflows/_release.yml is the _only test step in its job that calls uv sync/uv run directly instead of via just (deliberately, to avoid uv run re-syncing away the lowest-direct resolution). That step never sees .local_atlas_uri, so any test that relies on the MONGODB_URI env var falls back to each test file's hardcoded default (mongodb://localhost:27017), which is wrong whenever the container's random port isn't literally 27017.

In _release.yml, which only ever starts local Atlas (no other Mongo service), this manifests as a hard failure: pymongo.errors.ServerSelectionTimeoutError: localhost:27017: Connection refused. Hit while attempting to release langgraph-store-mongodb 0.4.0 (INTPYTHON-1043), job: https://github.com/langchain-ai/langchain-mongodb/actions/runs/33805996244/job/100816586312

In test.yml, which also starts a separate community MongoDB via supercharge/mongodb-github-action on the fixed default port 27017 (used for the earlier "Run unit tests" step), the same minimum-deps step's fallback silently connects to _that community instance instead of local Atlas — a quieter version of the same bug (testing against the wrong deployment) rather than a crash.

This step was added 2026-08-24 (commit 402bddc); this may be the first real release run to exercise the _release.yml code path since then.

Definition of done

What must be done to consider the task complete?

Export MONGODB_URI from .local_atlas_uri into $GITHUB_ENV immediately after the "Start local Atlas" step in both _release.yml and _test.yml, so every subsequent step in the job (whether invoked via just or raw uv run) sees the correct dynamic connection string. Leave start_local_atlas.sh's random-port behavior and _test.yml's separate community-MongoDB step unchanged — both are reasonable as-is; only the propagation gap needs fixing.

Pitfalls

What should the implementer watch out for? What are the risks?

_release.yml's build job (and therefore the whole pipeline) is gated to github.ref == 'refs/heads/main', so this fix cannot be dry-run via a normal branch/PR against _release.yml — only _test.yml's equivalent step can be exercised off main, and even then it won't reproduce the exact failure mode (it'll silently pass against the wrong Mongo instead of crashing) due to the redundant community-Mongo service.