frameworks/fulmine: bump to fulmine.js 5.12.2 - #1182
Conversation
|
The three compose FAILs are not this bump: the gateway and production-stack compose files pin cpuset 0-15,64-79 and 16-31,80-95, which are the benchmark host cores, and the validate runner has 0-3. Nothing sets PROXY_CPUSET or SERVER_CPUSET during validation, so the defaults apply and docker refuses to create the container. It is the same story as REDIS_CPUSET, which validate.sh already leaves unpinned because validation is correctness-only; the compose profiles need the same treatment. Any gateway-subscribed entry has this on a small runner, trillium carries the same defaults. |
|
/benchmark --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
echo-ws, echo-ws-pipeline, echo-ws-limited and production-stack, are broken!? |
Hmm looks like something broke prod stack test
|
…nd say why a stack failed (#1189) production-stack failed on #1182 with nothing in the log but an exit code: Container httparena-fulmine-production-stack-authsvc-1 Error dependency authsvc failed to start dependency failed to start: container ...-authsvc-1 exited (101) [FAIL] gateway compose up failed 101 is a Rust panic. Building frameworks/_shared/authsvc and running it twice reproduces it exactly: on a clean host it logs "authsvc listening on 0.0.0.0:9090" and answers /_health 200; with 9090 already held it exits 101 with "bind 0.0.0.0:9090: Address in use (os error 98)". Nothing about that is fulmine's. authsvc is the shared sidecar every production-stack entry builds, and every gateway and production stack runs network_mode: host on the same fixed ports - edge 8443, authsvc 9090, server 8080 - so no two can coexist. gateway_up already runs `down --remove-orphans`, but scoped to this framework's own compose project, so a stack left behind by another entry, or by a run killed between profiles, survives it. The only broader sweep is the one benchmark.sh does once at startup. _gateway_clear_stale() now removes running containers belonging to any other httparena-* compose project just before `up`, naming what it removed. It matches on the compose project label, so the harness's own `docker run` sidecars - httparena-postgres, httparena-redis - carry no such label and are untouched. The listing is split on `|` rather than whitespace: an unlabelled container prints an empty field, and with whitespace splitting its name would shift into the label's position and match the httparena- test by accident. The second half is why this took a rebuild to diagnose at all. compose reports the exit code and nothing else, so the reason never reached the run log. _gateway_dump_logs() prints each container of the failed stack through the existing dump_container_logs(), so the next failure names itself: ─── httparena-...-authsvc-1 — status=exited exit=101 oom=false error= ─── httparena-...-authsvc-1 — last 120 log lines ─── | bind 0.0.0.0:9090: Address in use (os error 98) Verified against real containers: two stale stacks from other projects are found, named and removed while an unlabelled sidecar survives, and a stack whose service exits 101 has its stderr printed. Leaves authsvc alone. Refusing to start when its port is taken is correct; the bug was the port still being taken.
d67f77d to
ceb6be6
Compare
|
/benchmark --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f fulmine -t production-stack --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f fulmine -t echo-ws --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f fulmine -t echo-ws-pipelined --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
|
/benchmark -f fulmine -t echo-ws-limited --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework: No results captured Full log |
|
/benchmark -f fulmine -t echo-ws-pipeline --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
Benchmark ResultsFramework:
Full log |
|
Bumped to 5.12.2. 5.12.1 and 5.12.2 are correctness fixes only, all found by fuzzing the router against Express: request framing (a repeated or unparseable None of it touches the hot path. Measured with the repo's own A/B and a null control from the same sitting: hello-world 1.5% and routes-1000 1.9%, against a null floor of 2.0%, so nothing moved that the harness can see. The number of routes still registered natively is unchanged on every benchmark scenario, which is the thing that change could have hurt. Worth flagging about the previous run: 10 of the 38 tests this entry subscribes to produced no result. The two /benchmark --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
|
👍 From our side this is ready: the entry itself is unchanged, only the dependency moved, and 5.12.2 is on npm. Mergeable as far as we are concerned. Left as a draft only until the benchmark run above comes back, so the saved numbers match the version being pinned. Happy for it to be merged whenever suits you. |
Benchmark ResultsFramework:
Full log |
97771bc to
4623c14
Compare
4623c14 to
6c8ea70
Compare
|
/benchmark --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
fulmine.js 5.12.0 is out, this bumps the entry to it.
The change that matters for the profiles is on the body path: a chunked request body is now collected natively in one callback, where before it was one callback and one copy per chunk. The rest of the release is router and settings work on paths the entry already takes, plus fixes.
No changes to the entry itself.