aws-samples / aws-samples/sample-autonomous-cloud-coding-agents

fix(compute): registry MCP assets are not substrate-portable to lambda-microvm

Open
#818 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
143
Forks
46
Avg merge
3d 9h
Merged PRs (30d)
20

Description

## Problem

`resolved_assets` (#246/#665) reaches the guest on `lambda-microvm` without any strategy change — traced and confirmed: `orchestrator.ts:999` puts it on the shared `agentPayload`, the MicroVM strategy forwards that verbatim (inline or via S3), `server.py:2122 _extract_invocation_params` → `:566` → `:677` → `_spawn_background(**params)` → `_run_task_background(resolved_assets=…)` → `pipeline.py:1167 apply_resolved_assets`, which is pure-local (writes `.mcp.json`, makes no AWS calls). So the delivery path is genuinely free.

Two constraints make *execution* of those assets non-portable, and neither is recorded anywhere:

1. **443-only runtime egress.** `LambdaMicrovmCompute`'s runtime security group is `allowAllOutbound: false` with a single TCP 443 rule (`lambda-microvm-compute.ts:862-870`). A registry `mcp_server` asset whose runtime config points at any other port works on `agentcore` and `ecs` and fails on `lambda-microvm`. `apply_mcp_assets` is fail-CLOSED on load errors but cannot see a connectivity constraint, so the symptom is a task that starts normally and then cannot reach its tool.
2. **`resolved_assets` consumes the 4 096-byte `runHookPayload` budget.** That cap is exact and measured (`lambda-microvm-strategy.ts:100-125`), and it is the branch point between inline and S3-pointer delivery. Adding asset entries shifts which tasks inline. Not a bug — the S3 path is already dominant — but it is an untested interaction: no test covers an envelope that crosses 4 096 bytes *because of* `resolved_assets`.

## Expected

- Document the 443-only constraint where registry assets are described (`docs/design/REGISTRY.md`) and in the `lambda-microvm` section of `COMPUTE.md` / `DEPLOYMENT_GUIDE.md`.
- Decide whether to validate it: either a synth/onboarding-time check that a pinned `mcp_server` asset's runtime is 443-reachable, or an explicit "not supported on this backend" note.
- Add a strategy test that pushes an envelope over 4 096 bytes via `resolved_assets` specifically and asserts the S3-pointer branch is taken.

Refs #645, #246, #665. Blocked by nothing; P2.

Contributor guide

Open the contributing guide

Research direction

Start with lambda-microvm-strategy.ts:100-125 and the asset path through orchestrator.ts:999, server.py:2122, and pipeline.py:1167; inspect the existing strategy tests and run them. Done means the 443-only limitation is documented in docs/design/REGISTRY.md, COMPUTE.md, and DEPLOYMENT_GUIDE.md, and a test covers resolved_assets forcing the over-4,096-byte S3-pointer branch.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, python, typescript
Domain
cloud, documentation, infrastructure, testing
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.