[BUG] HTTP API Lambda REQUEST authorizer: context is not forwarded to the integration event

[tomdmitchell]

Service

API Gateway v2 (HTTP API) + Lambda

AWS API Action

apigatewayv2 CreateAuthorizer - REQUEST type, payload format 2.0, --enable-simple-responses.

Expected behavior

When a Lambda REQUEST authorizer returns a simple response containing context, API Gateway merges it into the integration event at requestContext.authorizer.lambda:

{ "authorizer": { "lambda": { "foo": "bar" } } }

Confirmed against real API Gateway (eu-west-1) with identical authorizer configuration.

Actual behavior

The context is discarded. The integration event's requestContext has no authorizer key at all, so the response body is {"authorizer":null}. No error or warning is emitted — the request succeeds and the omission only surfaces in the handler.

The decision path itself is correct, which narrows this to the context merge:

Reproduction

export AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test AWS_DEFAULT_REGION=us-east-1
awsl() { aws --endpoint-url http://localhost:4566 --region us-east-1 "$@"; }
ACC=000000000000

cat > fn.js <<'EOF'
exports.handler = async (event) =>
  event.type === 'REQUEST'
    ? { isAuthorized: true, context: { foo: 'bar' } }
    : { statusCode: 200, body: JSON.stringify({ authorizer: event.requestContext.authorizer ?? null }) };
EOF
rm -f fn.zip && zip -q fn.zip fn.js

awsl lambda create-function --function-name repro --runtime nodejs20.x \
  --role arn:aws:iam::$ACC:role/test --handler fn.handler --zip-file fileb://fn.zip

API_ID=$(awsl apigatewayv2 create-api --name repro --protocol-type HTTP \
  --query ApiId --output text)

INT_ID=$(awsl apigatewayv2 create-integration --api-id $API_ID \
  --integration-type AWS_PROXY --payload-format-version 2.0 \
  --integration-uri arn:aws:lambda:us-east-1:$ACC:function:repro \
  --query IntegrationId --output text)

AUTH_ID=$(awsl apigatewayv2 create-authorizer --api-id $API_ID --name ctx \
  --authorizer-type REQUEST --identity-source '$request.header.Authorization' \
  --authorizer-payload-format-version 2.0 --enable-simple-responses \
  --authorizer-result-ttl-in-seconds 0 \
  --authorizer-uri arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:$ACC:function:repro/invocations \
  --query AuthorizerId --output text)

awsl apigatewayv2 create-route --api-id $API_ID --route-key 'GET /ctx' \
  --target integrations/$INT_ID --authorization-type CUSTOM --authorizer-id $AUTH_ID

awsl apigatewayv2 create-stage --api-id $API_ID --stage-name test --auto-deploy

curl -s -H 'Authorization: anything' \
  "http://localhost:4566/restapis/$API_ID/test/_user_request_/ctx"

# expected: {"authorizer":{"lambda":{"foo":"bar"}}}
# actual:   {"authorizer":null}

Environment

Floci version / image tag: 1.7.0, floci/floci:latest-compat (edition: community, original_edition: floci-always-free)
Java SDK version (if applicable): n/a — Node.js 20 Lambdas, AWS CLI v2
How you're running Floci: Docker, via docker compose

Note

Similar to issue #574, but to be applied to HTTP API v2

[github-actions]

👋 Thanks for opening your first issue in Floci!

A maintainer will triage this and add the right service label. If you included a minimal reproduction and the Floci version, that is everything we need — no action required from you right now.

Come say hi in Slack if you want to talk it through with maintainers and other contributors. Questions about AWS behaviour, design tradeoffs, and rough proposals are all welcome there.