fix(vtex): read MESH_REQUEST_CONTEXT per-request, not from cached factory env

[viktormarinho]

Summary

Switch every vtex tool's execute to read MESH_REQUEST_CONTEXT from runtimeContext.env (per-request, filled by the runtime's AsyncLocalStorage) instead of from the env captured in the factory closure. Affects:

• server/lib/tool-adapter.ts — createToolFromOperation (used by all ~705 generated registry tools)
• server/tools/custom/reorder-collection.ts — VTEX_REORDER_COLLECTION
• server/tools/custom/search-collections.ts — VTEX_SEARCH_COLLECTIONS
• server/tools/custom/update-product-specifications.ts — VTEX_UPDATE_PRODUCT_SPECIFICATIONS

Why this is the actual root cause

Studio is doing the right thing: I confirmed by introspecting the farmrio connection (COLLECTION_CONNECTIONS_GET conn_9uNQJVyv_ECiRcDZl290Y) that configuration_state is { accountName: \"lojafarm\", appKey, appToken } — fully populated — and buildRequestHeaders mints a JWT with that state and forwards it as x-mesh-token to https://sites-vtex.decocache.com/mcp.

The bug was in vtex. @decocms/runtime caches tool registrations after the first request (tools.ts: let cached: Registrations | null) and creates a fresh bindings env per request (index.ts: env: { ...process.env, ...env }). Tools that capture env in the factory closure see only the FIRST request's env — every subsequent call uses that frozen snapshot. The runtime's own comment at tools.ts:821 explicitly says: "Tool execution reads per-request context from State (AsyncLocalStorage), so reusing definitions is safe." — implying tools must read from runtimeContext.env, not the captured factory env.

Symptom: when the pod's first request happened to carry a state-bearing JWT, every subsequent call appeared to work. When the first request was an unauthenticated tools/list (typical right after a Knative scale-up), every subsequent call saw state: {} and failed with "VTEX accountName is missing" — the exact intermittent behavior reported ("worked for a little bit then back to error").

Verified by direct port-forward to the pod with a fake x-mesh-token containing state — the captured-env code returned hasToken: false regardless of what the request actually carried.

Test plan

• bun run check — clean
• bun test — 77 pass, 0 fail (mock runtimeContext.env propagates correctly through all paths)
• bun run build — bundles cleanly
• After deploy, confirm the diagnostic log in client-factory.ts flips from stateKeys: [] to stateKeys: [\"accountName\", \"appKey\", \"appToken\"] and VTEX_GET_COLLECTION_PRODUCTS returns real data
• Verify across pod scale events — the bug was timing-dependent, so the fix should be insensitive to which request hits a fresh pod first

Once verified, follow-up PR can strip the diagnostic logging added in #423.

Note about #430

The runtime bump in #430 (1.3.1 → ^1.6.2) didn't fix anything by itself — both runtime versions had the cached-registrations behavior — but it doesn't hurt and cleans up some unrelated divergence from the recent rollback, so I'm leaving it merged.

🤖 Generated with Claude Code

---

Summary by cubic

Fix VTEX tools to read MESH_REQUEST_CONTEXT from per-request runtimeContext.env instead of the cached factory env. This removes state leakage across requests and fixes intermittent “VTEX accountName is missing” errors after cold starts or unauthenticated first calls.

• Bug Fixes

  • Read MESH_REQUEST_CONTEXT from runtimeContext.env in createToolFromOperation and custom tools: VTEX_REORDER_COLLECTION, VTEX_SEARCH_COLLECTIONS, VTEX_UPDATE_PRODUCT_SPECIFICATIONS.
  • Avoids using a cached env snapshot from tool registration; tools now receive the correct state on every call.

• Dependencies

  • Bump @decocms/runtime to ^1.6.2 and @decocms/bindings to ^1.4.0.
  • Add @modelcontextprotocol/sdk to dependencies at ^1.27.1 (was in devDependencies).

^{Written for commit c05b085. Summary will update on new commits.}