Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#818 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

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

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.

Description

v1

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.

Dominant language
TypeScript
Stars
158
Forks
49
Avg merge
3d 7h
Merged PRs (30d)
17

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

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

All issues in aws-samples/sample-autonomous-cloud-coding-agents

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.