Ensure build instance replacement on rack version updates#3780
Closed
Ensure build instance replacement on rack version updates#3780
Conversation
ntner
added a commit
that referenced
this pull request
Mar 26, 2026
## Summary
- Add `Version` parameter reference to `BuildLaunchTemplate` UserData to guarantee a new LaunchTemplate version is created on every rack update
- Eliminates a race condition where the rack API receives new TLS certificates before the build instance is replaced, causing a `tls: unknown certificate authority` error window during updates
## Background
During a rack version update, self-signed Docker TLS certificates are regenerated by a CloudFormation custom resource Lambda. The rack API ECS tasks restart with the new certificates quickly, but the build EC2 instance replacement depends on CloudFormation detecting a change in the `BuildLaunchTemplate` UserData (via custom resource output propagation). If that propagation chain doesn't produce a detectable change, the ASG rolling update is not triggered, leaving the build instance running with stale certificates.
Even when the rolling update IS triggered, the API tasks can restart with new certificates before the build instance replacement completes, creating a failure window where builds fail with:
```
remote error: tls: unknown certificate authority
```
## Change
One line added to `BuildLaunchTemplate` UserData in `provider/aws/formation/rack.json`:
```json
"# rack-version: ", { "Ref": "Version" }, "\n",
```
This is a cloud-config comment with no effect on instance boot behavior. Because `{ "Ref": "Version" }` resolves to a different value on every rack version update, the UserData content always changes, which forces a new LaunchTemplate version, which triggers the `AutoScalingRollingUpdate` policy on the `BuildInstances` ASG.
ntner
added a commit
that referenced
this pull request
Mar 30, 2026
* [#3781] Modernize G1 Lambda, CI, kubectl, Fargate regions ## Summary Pre-NLB chore release bundling deferred maintenance items that carry zero customer-facing risk individually and benefit from shipping together. - **G1 CronFunction:** Migrate inline Lambda from nodejs16.x/AWS SDK v2 to nodejs22.x/AWS SDK v3 (nodejs16.x is EOL; nodejs18+ does not bundle SDK v2) - **Fargate region map:** Enable Fargate in ap-northeast-1, ca-central-1, us-west-1 (supported since 2018-2019, flags were stale) - **GitHub Actions:** Bump checkout@v4, setup-go@v4 with go-version-file, set-output deprecation fix, qemu@v3, buildx@v3 - **kubectl:** Bump v1.13.0 to v1.28.15 in Dockerfile, Dockerfile.arm, ci/dependencies.sh (debug-only binary, not in operational path) ## Details ### G1 CronFunction (provider/aws/formation/g1/app.json.tmpl) Runtime and SDK must change together -- nodejs18+ does not ship `aws-sdk` v2. The rewrite preserves exact functional behavior: | Aspect | Before | After | |--------|--------|-------| | Runtime | nodejs16.x | nodejs22.x | | ECS client | `new aws.ECS({maxRetries:10})` | `new ECSClient({maxAttempts:11})` | | CW Logs client | `new aws.CloudWatchLogs()` | `new CloudWatchLogsClient({})` | | Handler | callback-based (`cb`) | async/await | | Skew delay | `setTimeout(fn, skew)` | `await new Promise(r => setTimeout(r, skew))` | - Only affects Generation 1 apps, only on next CF update (deploy/scale/param change) - Failure mode: cron tasks don't fire (not rack-down, not resource destruction) - Lambda ARN preserved; EventBridge rules and CronRole IAM unchanged ### Fargate region map (provider/aws/formation/rack.json) Pure metadata update. The `Fargate` mapping value feeds into a Docker label and a CF Output, but `p.Fargate` is set-but-never-read in Go code. No CF Conditions gate on this value. Service-level Fargate still requires explicit `Fargate=Yes` in convox.yml. ### GitHub Actions (.github/workflows/release.yml, publish.yml) CI-only changes. Node 16 action runners are deprecated by GitHub. `go-version-file: go.mod` pins Go version deterministically (previously relied on runner default). ### kubectl (Dockerfile, Dockerfile.arm, ci/dependencies.sh) kubectl is installed in the rack image for debugging only -- not called from any Go code. v1.13.0 is from December 2018. Docker CLI versions intentionally not changed (requires AMI coordination). ## Not changed - Docker CLI versions in Dockerfiles - AWS SDK Go version - Any Go source code - service.json.tmpl or app.json.tmpl (Gen 2) - Resource templates (postgres, redis, valkey, etc.) * [#3780] Ensure build instance replacement on rack version updates ## Summary - Add `Version` parameter reference to `BuildLaunchTemplate` UserData to guarantee a new LaunchTemplate version is created on every rack update - Eliminates a race condition where the rack API receives new TLS certificates before the build instance is replaced, causing a `tls: unknown certificate authority` error window during updates ## Background During a rack version update, self-signed Docker TLS certificates are regenerated by a CloudFormation custom resource Lambda. The rack API ECS tasks restart with the new certificates quickly, but the build EC2 instance replacement depends on CloudFormation detecting a change in the `BuildLaunchTemplate` UserData (via custom resource output propagation). If that propagation chain doesn't produce a detectable change, the ASG rolling update is not triggered, leaving the build instance running with stale certificates. Even when the rolling update IS triggered, the API tasks can restart with new certificates before the build instance replacement completes, creating a failure window where builds fail with: ``` remote error: tls: unknown certificate authority ``` ## Change One line added to `BuildLaunchTemplate` UserData in `provider/aws/formation/rack.json`: ```json "# rack-version: ", { "Ref": "Version" }, "\n", ``` This is a cloud-config comment with no effect on instance boot behavior. Because `{ "Ref": "Version" }` resolves to a different value on every rack version update, the UserData content always changes, which forces a new LaunchTemplate version, which triggers the `AutoScalingRollingUpdate` policy on the `BuildInstances` ASG. * [#3779] fix docker version mismatch in test mocks ### What is the feature/fix? Fix TestBuildExport failure caused by Docker CLI version mismatch in test mocks ### Does it has a breaking change? no ### How to use/test it? Run CI * ci fix cache class * ci fix * remove s3/sqs/sns rack resource from ci pending servicerole rework
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is the feature/update/fix?
Fix: Build Instance Replacement on Rack Version Updates
We've resolved a race condition that could cause builds to fail with a
tls: unknown certificate authorityerror during rack version updates. The issue occurred because self-signed Docker TLS certificates are regenerated on every rack update, and the rack API ECS tasks would restart with the new certificates before the build EC2 instance was replaced — leaving the build instance running with stale certificates.The root cause was that CloudFormation did not always detect a change in the build instance's launch template UserData, so the ASG rolling update was not triggered. The fix adds a rack version reference to the launch template UserData, guaranteeing that a new launch template version is created on every rack update, which forces the build instance to be replaced.
How to use it?
This fix is automatically applied when you update your rack. No additional configuration is required.
If you were previously experiencing intermittent
tls: unknown certificate authorityerrors during or shortly after rack updates, this will resolve the issue.Does it have a breaking change?
No breaking changes. The build instance replacement behavior is now more reliable — existing build workflows continue to function as before.
Requirements
To receive this fix, you must update to rack version
20260330131343or newer.convox rackconvox rack update