CI: unblock nightlies by dropping the /using-ssr framework-test route - #121
Merged
Conversation
Every push to main since 2026-06-30 has failed, so publish-nightly (which needs all three build jobs) has never run to completion and no nightly has shipped since then. Two distinct causes: - Runs up to #119 reached publish-nightly and died in `wasmer publish` with `Path: "./etc" does not exist`. Fixed by 37b039c (#120), but that fix has never had a green run to prove it. - The last two runs fail earlier, in the framework tests, and this is the one still outstanding. js-gatsby-staticsite2's /using-ssr route calls an external API (dog.ceo) from getServerData(). On GitHub runners that fetch hangs rather than failing fast, so the harness's 5s HTTP_REQUEST_TIMEOUT_MS expires and the job fails — note the failure is on the *Node.js baseline* stage, with EdgeJS itself passing clean. #108's "accept 200 or 500" tolerance does not help: it only applies when the fetch fails fast enough for getServerData()'s catch block to render a response, and a timed-out request never reaches a status assertion. Bump wasmer-examples to drop the route. It was already node-only, since EdgeJS stages serve Gatsby from static public/ output rather than running `gatsby serve` (which hard-requires the lmdb native addon), so it validated nothing about EdgeJS and only gated CI on a third party's uptime. Requires wasmerio/examples#4. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
Every push to
mainsince 2026-06-30 has failed.publish-nightlyisneeds:-gated on all three build jobs, so one red build skips publishing entirely — no nightly has shipped since, andwasmer/edgejs-quickjson the registry is stuck at 0.0.7 (2026-07-06).Two distinct causes, in sequence:
1. The publish step itself (run 29591734564, #119) — all three builds went green,
publish-nightlyran, uploaded the GitHub release assets, then died:Already fixed by 37b039c (#120) — but that fix has never had a green run to prove it, because of:
2. Framework tests (runs 29598931774 and 29624846373) —
js-gatsby-staticsite2fails on the Node.js baseline stage, with EdgeJS passing clean:The route's
getServerData()fetchesdog.ceo/api/breed/shiba/images/random. On GitHub runners that fetch hangs rather than failing fast — the previous route passed at01:36:43.150and the failure landed at01:36:48.180, exactly the harness's 5sHTTP_REQUEST_TIMEOUT_MS.#108's "accept 200 or 500" tolerance doesn't help: it only applies when the fetch fails fast enough for the
catchblock to render a 500. A timed-out request never reaches a status assertion.What
Bumps
wasmer-examplesto drop the route (wasmerio/examples#4).It was already
"stages": ["node"]-only. Verified why: EdgeJS stages serve Gatsby from staticpublic/output instead of runninggatsby serve, becausegatsby servehard-requires thelmdbnative addon and crashes EdgeJS outright (undefined symbol: napi_module_register— the legacyNAPI_MODULEentry, referenced from a static ctor duringdlopen(), so it's an uncatchable linker error rather than a JS exception). So the route validated nothing about EdgeJS and only gated CI on a third party's uptime./using-dsgstays — also node-only, but served from build output with no external dependency.Test
passes both stages, 3/3 routes each, no regressions. Before the change, the same command reproduces the edge-stage 404 when the node-only gate is lifted, confirming the static-serving analysis.
Merge order
wasmerio/examples#4 first, then this. The submodule pointer here references a commit that currently only exists on that PR's branch.
Follow-ups (not in this PR)
src/edge_process.ccstill has livedlopenmachinery. A decision to ban addon loading outright (native/WASIX parity) shipped in EdgeJs WASIX C-ARES and OpenSSL fixes and Node test runner #91, was reverted by 237068a, and a7bf290 ("Reinstate EdgeJs WASIX C-ARES and OpenSSL fixes and Node test runner #91") restored the framework-test changes but not the ban — so legacy-prebuild loads can still take the process down. Native and WASIX are currently inconsistent here.🤖 Generated with Claude Code