# Lambda Rollout Correction Guide

Use this reference when fixing Lambda aliases, versions, CodeDeploy/SAM traffic shifting, event-source mappings, destinations, DLQs, or serverless rollout wiring in repository files.

## What people get wrong

The lazy story is:

> It is just a Lambda config fix; update the template and redeploy.

Wrong. Serverless rollout defects often hide in alias/version traffic, event-source semantics, retries, and alarms. A repo patch can make the next deployment worse if it ignores those boundaries.

Common bad assumptions:

- `$LATEST` is acceptable in production rollout wiring.
- Alias changes are harmless because code is immutable.
- Event-source mapping changes are not production-impacting.
- CodeDeploy hooks are optional ceremony.
- DLQ/destination changes do not affect audit or replay.
- A SAM/AppSpec diff proves runtime rollback readiness.

## Service-specific failure modes

- Alias points to the wrong published version or shifts traffic to unvalidated code.
- Provisioned concurrency is attached to the wrong alias/version.
- CodeDeploy deployment preference lacks alarms or lifecycle validation hooks.
- Event source mapping batch size, maximum batching window, filter criteria, or starting position changes replay/latency behavior.
- SQS/Lambda partial batch response settings are missing or inconsistent.
- Async destinations or DLQs are removed during a hotfix.
- IAM permission changes break event-source polling, log writes, or downstream calls.

## Minimum safe workflow

1. Identify the rollout mechanism: SAM, CloudFormation, CDK, Terraform, Serverless Framework, or raw config.
2. Identify the release primitive: Lambda version, alias, CodeDeploy deployment group, event source mapping, API stage, or EventBridge rule.
3. Patch the smallest repo field that corrects the defect.
4. Preserve existing rollback path: previous alias target, previous mapping config, previous deployment preference, or previous template version.
5. Run local validators for the IaC/framework in use.
6. State what the patch changes at runtime and what it does not execute.
7. Require explicit approval before deploy, rollback, publish-version, alias update, or event-source mutation.

## Verification targets

Use repo and read-only evidence where available:

- Lambda alias/version references in templates
- CodeDeploy deployment preference, alarms, and lifecycle hooks
- event-source mapping config: source ARN, batch size, filters, enabled state, destinations
- function timeout, memory, reserved/provisioned concurrency
- DLQ and async destination configuration
- IAM permissions for invoke, poll, log, and downstream calls
- validation commands such as `sam validate`, `cfn-lint`, `cdk synth`, `terraform validate`, or project tests

## When to push back

Push back if the user asks to:

- patch rollout config and immediately deploy without approval
- remove alarms/hooks to make a deployment pass
- point production aliases at `$LATEST`
- disable event-source mappings without a replay plan
- “fix” retries by dropping failures silently
- claim rollback is safe without a previous alias/version target

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html
- https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-example.html
- https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html
- https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- CodeDeploy can automate Lambda deployments with traffic shifting, AppSpec files, lifecycle hooks, and rollback behavior depending on deployment configuration.
- Lambda versions and aliases are release-control primitives; aliases can route traffic to published versions while function code/config versions remain immutable.

Sampled live evidence:
- Read-only regional availability sampling reported Lambda, CodeDeploy, and CloudFormation as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `Lambda+GetFunction` and `CodeDeploy+GetDeployment` were reported `isAvailableIn` in those regions.

Review implications:
- Repo-side rollout correction must identify alias/version, traffic shift, lifecycle hook, alarm, and rollback target; it must not execute live rollback/deploy unless explicitly approved.
- Syntax-correct SAM/AppSpec is not proof of safe rollout behavior.

# Safety checklist

- Do not ask for or print secrets, credentials, access tokens, private keys, account numbers, or customer identifiers.
- Keep edits minimal and reversible.
- Do not perform live cloud mutation by default.
- Surface rollback implications and missing validation explicitly.
- Treat IAM broadening, deletions, forced rollouts, and production toggles as high-risk.

# Workflow and output contract

Use this reference for full write-capable AWS patch work.

## Workflow

1. Classify the repo-side correction.
2. Confirm the target files and blast radius.
3. Make the smallest reversible edit.
4. Run local validators or syntax checks.
5. Report exact files changed, validation results, and rollback path.

## Guardrails

- Repo write access is allowed.
- Live AWS mutation is out of scope by default.
- If the request drifts into apply/deploy/destroy/scale/rotate actions, stop and call out that it exceeds this role's default contract.