fix(compose): pin all deno images to 2.7.9, drop floating latest - #137
Merged
Conversation
The frontend console services in every compose suite ran denoland/deno:latest while the backend platforms pin 2.7.9. deno:latest now resolves to 2.9.x, where the minimum dependency age policy (default 24h) is enforced at install and esbuild deno-loader resolution, even with a committed deno.lock. This broke the invite-gate suite on moonlight-pay PR 44: jsr @moonlight/moonlight-sdk 0.13.0 was published less than 24h before the run, the moonlight-pay container failed deno install and deno task build, served without a fresh bundle, and the connect button never rendered. The same footgun applies to every suite here on any bump PR opened within 24h of a JSR publish. Pin every denoland/deno image to 2.7.9 to match the backends and the 2.7.x pins in repo CI workflows, so a floating tag cannot silently change dependency resolution behavior again.
The reusable invite-gate workflow dumped container logs but discarded the Playwright test-results directory when the compose stack came down, so error-context.md, failure screenshots, and traces (which carry the browser console) were unrecoverable. Copy them out of the stopped test-runner container and upload as a run artifact so browser-side failures like the moonlight-pay connect button regression can be diagnosed directly.
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.
Why
The invite-gate failure on moonlight-pay PR #44 (run 30389517406) was not a stellar-sdk 16 browser regression. The moonlight-pay container log shows the actual error:
jsr @moonlight/moonlight-sdk 0.13.0 was published 2026-07-28 17:43 UTC, 1h54m before the run. The frontend services run
denoland/deno:latest, which now resolves to 2.9.x where Deno's minimum dependency age policy (default 24h) is enforced atdeno installand at esbuild deno-loader resolution, even with a committed deno.lock in the container. The build failed, the container served without a fresh bundle, and#connect-btnnever rendered. The consoles passed only because their deps are all older than 24h.The backend services already pin
denoland/deno:2.7.9and the repo CI workflows pin Deno v2.7.x, which is why the same moonlight-pay commit was green in Tests and Deploy. No repo in the org configures min-dep-age anywhere; the floating tag silently changed CI resolution behavior when:latestrolled forward.What
Pin every
denoland/deno:latesttodenoland/deno:2.7.9(21 occurrences, 11 compose files: e2e, otel, governance, invite-gate, pos-instant, playwright, lifecycle, multi-asset suites plus the e2e/, lifecycle/, multi-asset/ standalone files). No other changes.Without this, every suite here fails on any bump PR opened within 24h of a JSR publish.