Remote state + MODELLING_E2E_SQS_URL env var + send policy ARN, and
fast_api_lambda deploys after modelling_e2e_lambda so the remote state
exists before it applies.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The /v1/bulk-uploads/trigger-landlord-overrides endpoint reads
settings.LANDLORD_OVERRIDES_SQS_URL, but the fast-api Lambda's terraform
never set it, so it fell back to the config default "changeme" and
SendMessage failed with AWS.SimpleQueueService.NonExistentQueue.
The landlord-overrides queue (and its finaliser sibling) were added to the
router/config but only the finaliser was wired here. This adds the missing:
- terraform_remote_state data source for the queue's state
- LANDLORD_OVERRIDES_SQS_URL env var on the FastAPI Lambda
- queue ARN in the fastapi-sqs-send IAM policy (else AccessDenied)
Mirrors the existing postcode-splitter / combiner / finaliser wiring.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
/health already returned GITHUB_SHA in its response but never logged
it, and the fastapi lambda's Terraform environment never actually set
GITHUB_SHA — so every health check response contained "unknown" in
production. Wire var.github_sha through the fastapi lambda module
(default "unknown" for local/other invocations) via a new
TF_VAR_github_sha env var set from `github.sha` in
_deploy_lambda.yml's Terraform Plan step, and log it on every /health
call so a request in CloudWatch can be tied back to the deploy that
served it.
Also fix the zip-size gate added for PR #1469: putting it in
tests/test_lambda_zip_size.py (run via the Docker-based ddd_tests.yml
suite) broke CI, because Dockerfile.test's build context excludes
deployment/* (.dockerignore), so check_lambda_zip_size.py couldn't
find variables.tf to read zip_excludes from inside that container.
Move the check to its own lightweight workflow,
check_lambda_zip_size.yml, triggered on pull_request into main — a
plain checkout (no Docker build) has the full repo, so the check
works, runs fast, and still gates merges to main before a regression
can roll into the dev deploy.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
dev deploys have failed since PR #1231 (2026-06-15) with
InvalidParameterValueException: Unzipped size must be smaller than
262144000 bytes. The lambda zip is built from the whole repo root
(deployment/terraform/modules/lambda_with_api_gateway) and only
excluded tests/deployment/pycache — so .git (206MB packed), the
per-schema corpus.jsonl fixtures under backend/epc_api/json_samples/
(~50MB), and the sap10_calculator PDF specs (~13MB) were all being
zipped up even though none of them are read at runtime.
Also add scripts/check_lambda_zip_size.py, which mirrors the
terraform module's pip install + zip-with-excludes behaviour to
report the projected unzipped size without mutating the repo, and
wire it into deploy_terraform.yml as a fast_api_lambda_zip_size_check
job that gates the real deploy so this fails fast with a clear
message instead of surfacing as an opaque Terraform/AWS error.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Terraform computes SOLAR_MIN_REQUEST_INTERVAL_SECONDS = N / (0.8 * 600 / 60)
from var.maximum_concurrency (=4.0s at N=32) so the fleet width has one source
of truth and the per-container Solar pacing tracks it automatically.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
