feat: enable VPC Lattice support

[nanookclaw]

Enable VPC Lattice event support in the adapter by enabling lambda_http's existing vpc_lattice feature and updating the direct dependency from 1.1.1 to 1.2.0. The existing API Gateway, ALB, pass-through, tracing, and Tokio concurrency features are preserved. Cargo.lock is refreshed for the required Lambda crates.

This exposes the VPC Lattice V2 event support already implemented by lambda_http.

Validation:

• cargo fmt --all -- --check
• cargo metadata --locked --offline --format-version 1 --no-deps
• git diff --check
• cargo check --locked could not reach compilation because this environment could not resolve static.crates.io while downloading the newly locked lambda_runtime source.

Closes #789

[aws-sam-tooling-bot]

Code Review Results

Reviewed: 34d3a29..aa51114
Files: 2
Comments: 1

[aws-sam-tooling-bot]

[BUG] Adding another HTTP event variant alongside pass_through changes event classification, and nothing in this PR verifies that non-HTTP events still behave as before.

pass_through is the fallback variant of lambda_http's event enum, and it is the adapter's only mechanism for non-HTTP triggers. In src/lib.rs:

if matches!(request_context, RequestContext::PassThrough) && parts.method == Method::POST {
   path = self.pass_through_path.as_str();
}

Every SQS, SNS, S3, DynamoDB, EventBridge, and Bedrock Agent payload reaches the app only because it deserializes into PassThrough (documented in docs/guide/src/features/non-http-events.md, exercised by examples/sqs-expressjs and examples/bedrock-agent-fastapi). Enabling one more variant necessarily shrinks the set of payloads that reach that fallback. VPC Lattice payloads are shaped as loosely typed method / raw_path / headers / query_string_parameters / body / is_base64_encoded fields, so if those fields deserialize with defaults, an unrelated event JSON can match the Lattice variant instead of falling through. The failure is silent: the event would be forwarded as a GET to / with an empty body rather than POSTed to AWS_LWA_PASS_THROUGH_PATH, so a pass-through handler would simply stop receiving messages.

Two things are worth adding before merge:

1. A regression test asserting a non-HTTP payload still routes to the pass-through path. The current harness cannot express this — tests/integ_tests/common/mod.rs only builds ALB events:

pub enum LambdaEventType {
   #[default]
   ALB,
   // TODO: Add other event types
}

2. A test covering the new path itself: a VPC Lattice event producing the expected request path, query string, and x-amzn-request-context header. There is currently no coverage that the newly enabled variant works end to end through fetch_response, which derives the path from raw_http_path() and serializes the context into a header.

This matters more than usual here because the PR description notes cargo check --locked could not complete in the author's environment, so neither compilation nor the existing test suite has been run against the change.

[nanookclaw]

Added focused regression coverage in fe18556:

• The documented Bedrock Agent non-HTTP payload is classified as RequestContext::PassThrough and forwarded as POST to the configured pass-through path with its original JSON body.
• A VPC Lattice V2 POST preserves /health, both mode query values, the request body, and the complete x-amzn-request-context through Adapter::call.

Verification passed: cargo fmt --all -- --check, cargo metadata --locked --offline --format-version 1 --no-deps, and git diff --check. The focused cargo test remains blocked before compilation because this host lacks cached adler2 v2.0.1, and online resolution cannot reach static.crates.io. No production code or dependency files changed.

[aws-sam-tooling-bot]

Code Review Results

Reviewed: 34d3a29..fe18556
Files: 3
Comments: 1

---

Comments on lines outside the diff:

[Cargo.toml:31] [GENERAL] Adding vpc_lattice inserts another variant into lambda_http's event enum, which is matched untagged (variants are tried in declaration order, with pass_through as the fallback). The new tests cover the two ends of that ordering — a Bedrock Agent payload still resolving to RequestContext::PassThrough, and a VPC Lattice V2 payload resolving to RequestContext::VpcLattice — but nothing covers the variants in between.

That gap matters because no existing test deserializes a real event payload at all. LambdaEventBuilder::build() in tests/integ_tests/common/mod.rs returns LambdaRequest::Alb(...) directly, and the unit tests in src/lib.rs construct LambdaRequest::Alb / LambdaRequest::ApiGatewayV2 directly as well. Both bypass serde entirely, so if a VPC Lattice V2 payload shape overlaps an ALB or API Gateway payload shape (both carry path/headers/queryStringParameters/body/requestContext), the misclassification would produce a wrong x-amzn-request-context header and a wrong forwarded path with the entire suite still green. The e2e tests that would catch it are #[ignore]d and require a deployed stack.

Since the new tests already establish the pattern, the check is cheap to add:

#[test]
fn test_http_events_still_classify_after_enabling_vpc_lattice() {
   let alb = lambda_http::request::from_str(&alb_event_json()).expect("Failed to deserialize ALB event");
   assert!(matches!(alb.request_context(), RequestContext::Alb(_)));

   let apigw = lambda_http::request::from_str(&apigw_v2_event_json()).expect("Failed to deserialize APIGW event");
   assert!(matches!(apigw.request_context(), RequestContext::ApiGatewayV2(_)));
}

This is also worth confirming before merge because the PR description notes that cargo check --locked could not complete in this environment, so neither the new tests nor the feature combination have actually been compiled or run.

Note: Cargo.lock was reviewed only for consistency with the manifest change (version and checksum bumps for aws_lambda_events, lambda_http, lambda_runtime, lambda_runtime_api_client); as a generated lock file it is otherwise skipped.