Repository navigation
[plugin] lambda-build and lambda-deploy can disagree on target architecture (latent broken-function bug) #683
Description
Summary
lambda-build and lambda-deploy disagree about the target architecture, and nothing enforces consistency. This lets a user build for one architecture and deploy a function declaring the other, producing a function that fails to run — with no error at build or deploy time.
Details
lambda-buildhas no--architectureflag. The cross-compile container runs under the host/daemon's default architecture, and the produced binary's architecture is whatever the base image resolves to. There is no way to select it explicitly and no record of what was built.lambda-deploydoes have--architecture, defaulting toArchitecture.host(#if arch(x86_64)→x64, elsearm64), and passes it toCreateFunction.architectures.
Because the two sides choose the architecture independently, a mismatch is possible today — e.g. build produces an arm64 binary while deploy declares x64 (or the reverse if building on one host and deploying from another). The deployment "succeeds" but the function is broken at invoke time. The failure is latent: neither plugin validates that the deployed architecture matches the built binary.
Expected
lambda-buildshould accept--architecture <x64|arm64>(default: host) and build for that architecture explicitly (docker--platform linux/<arch>, Applecontainer--arch <arch>).- The built architecture should be recorded and consumed by
lambda-deployso its--architecturedefaults to what was actually built, rather than independently defaulting to the host. - A mismatch between an explicitly-requested deploy architecture and the built artifact should be a hard error, not a silently broken function.
Notes
This was discovered while designing OCI image support (where the image's single architecture is baked in and must match CreateFunction.architectures, making the mismatch fatal rather than latent). A build→deploy metadata handoff (e.g. a build manifest recording architecture) would address both this and the OCI case. Tracking the underlying architecture-consistency bug here independently of OCI.
Activity
sebsto commentedon Jun 29, 2026
Note on history: this is not a regression introduced by the v2 plugin rewrite (#567). The legacy
archive/packager plugin never had a build-side--architectureflag either — it only had--swift-version/--base-docker-imageand never passed--platformto docker, so it always built for the Docker daemon's default architecture.The deploy-side architecture parameter has existed independently since Jan 2023 (commit
f3f4021, in the oldDeploy.swiftdeployment descriptor), feedingCreateFunction.architectures. So the build-vs-deploy asymmetry is original to the plugins, not something lost in #567 — this issue closes a long-standing gap rather than restoring removed behaviour.sebsto commentedon Jul 1, 2026
Rescoping this after the OCI PR (#687), which built the build-manifest hand-off but only wired it into the image path.
Current state against the three expected items:
--architectureflag onlambda-build: still missing. Both backends hardcode.host(ZipArchiveBackend.swift, and makeArchiveBackend() which has a comment pointing back here).architecture, and the image deploy path reads it (Deployer+ECR.swift). But the ZIP deploy path still ignores it and usesconfiguration.architecture, which independently defaults to host (Deployer+Zip.swift). Since ZIP is the default format, the original latent mismatch is still fully present.manifest.architectureto the requested deploy architecture.So the OCI-fatal case is handled, but the underlying latent ZIP bug this issue tracks is not. Remaining work:
--architecture <x64|arm64>tolambda-build(default host), write it into the ZIP manifest instead of.hostdeployZipdefault its architecture tomanifest.architecture--architecturethat disagrees with the manifest a hard error[plugin] Enforce build/deploy architecture consistency (awslabs#683) (a…