fix(ci): unbreak release platform builds + lint gates#4857
Merged
Conversation
Release Packages v0.5.1150 failed on 5 of 19 build jobs and main's lint gate went red after #4853 merged with an admin bypass. This PR makes the next release tag green across all platforms: - perry-ui-android drag_drop.rs: E0597 `jstr` does not live long enough (broke both aarch64- and x86_64-linux-android). The `env.get_string(&jstr)` Result temporary outlived `jstr` as an if-let tail expression; bind the converted String first. Verified via `cargo check -p perry-ui-android --target aarch64-linux-android` with NDK r30. - rustfmt: format the four files #4853 merged unformatted (lint job was red on main). - file-size gate: body_stmt.rs hit 2038 lines (limit 2000); extract the for-await target-detection + iterator-close helpers into body_stmt/iter_helpers.rs (1819 lines now), no behavior change. - binary-size baseline: refresh to v0.5.1150 measured sizes following the v0.5.1122 precedent. libperry_runtime grew +34.8% over the 5-day v0.5.1122 → v0.5.1150 parity push (317 commits, 198 touching perry-runtime, +30.6k LOC) — verified broad organic growth, not a single pathological commit. Not fixed here (already on main): perry-ui-windows windows_core E0433 was fixed by #4837 two hours after the v0.5.1150 tag. The perry-cross-aarch64-apple-darwin upload failure was a transient GitHub API outage; the build itself succeeded.
e954db5 to
18215e5
Compare
added 2 commits
June 9, 2026 22:19
…perf regression gate Two intertwined Regression Check failures: 1. 03_array_write hang (every perf run cancelled at the 6h job timeout since v0.5.1129): #4648 introduced MAX_DENSE_ARRAY_GROW_LENGTH=1M as an absolute cap, so a sequential 10M-element fill routed 9M writes through string-keyed sparse properties — a linear-scan Vec per insert, i.e. quadratic. Sparse storage is now gated on the GAP the write creates (index - length > 1024) in addition to the absolute size, matching engine dictionary-mode heuristics: sequential growth (gap 0) stays dense at any size, far jumps (a[2**32-2] on a small array) stay sparse. Verified: 10M-element 03_array_write goes from hung (killed at 45s+, was 6h in CI) to ~3.3s, matching the last green run; both #4648 node-suite tests stay byte-identical to Node; new unit test pins the dense path. 2. The performance gate has been vacuous since at least v0.5.1122: compare.sh resolves --json-out after cd'ing into benchmarks/suite, so .bench-results/current.json was never written, the comparison crashed with FileNotFoundError, and the `| tee` pipeline (no pipefail in the default runner shell) swallowed the exit. Every release-mode "hard-fail" perf gate passed without comparing anything. Fixed: --json-out resolved to an absolute path up front, pipefail set in the workflow step, timeout-minutes: 100 on the job (healthy runs take ~20min), and benchmarks/baseline.json refreshed from the last green Regression Check run (27001035612, 2026-06-05) — the April c89b3ad numbers (array_write 3ms vs 3.1-3.4s measured on every June run) would hard-fail every release the moment the gate started working again.
#4648 put the sparse-index consult ahead of the dense bounds check in js_array_get_f64 / js_array_get_f64_unchecked, so every in-capacity read paid a non-inlined helper call (incl. a second clean_arr_ptr). The helper returns None below capacity by definition, so gating it on index >= capacity is exactly behavior-preserving and keeps the dense hot path call-free. Boundary node-suite test stays byte-identical to Node.
proggeramlug
added a commit
that referenced
this pull request
Jun 9, 2026
…dense-array growth hang, perf gate re-armed (#4862) 21 commits since v0.5.1150. Headline: PR #4857 — Android drag_drop E0597 (broke both android build-cross jobs), dense-array gap heuristic (sequential growth past 1M was quadratic via string-keyed sparse props; hung every Regression Check 6h since v0.5.1129), perf regression gate un-vacuumed (compare.sh --json-out path + pipefail + job timeout; gate had compared nothing since ≤v0.5.1122), binary-size + performance baselines refreshed (performance from post-fix workflow_dispatch run 27236538959). Windows windows-core dep (#4837) ships in a release for the first time. See CHANGELOG.md for the full block. Co-authored-by: Ralph Küpper <ralph@skelpo.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
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 v0.5.1150 Release Packages run failed on 5 of 19 build jobs (skipping npm/homebrew/apt/winget publish), and the Regression Check workflow has been failing or hanging on every run since June 6. Goal: a release tag where every platform build and every check is green — and actually means something.
What
build-crossandroid (both arches)perry-ui-android/src/drag_drop.rs:338—env.get_string(&jstr)Result temporary outlivesjstras if-let tail expressionStringfirst. Verified:cargo check --target aarch64-linux-android(NDK r30) cleanperformancecancelled at 6h on every run since v0.5.1129MAX_DENSE_ARRAY_GROW_LENGTH=1Mabsolute cap routed a sequential 10M-element fill through string-keyed sparse properties (linear-scan Vec per insert → quadratic).03_array_writenever finishedindex - length > 1024) in addition to absolute size, like engine dictionary-mode heuristics. 10M fill: hung → ~3.3s (matches last green run). Both #4648 node-suite tests stay byte-identical to Node; new unit test pins the dense pathcompare.shresolves--json-outaftercd benchmarks/suite→current.jsonnever written → comparison crashes →| tee(no pipefail) swallows the exit. Release-mode "hard-fail" gates passed without comparing anything--json-outresolved to absolute path up front;set -o pipefailin the workflow step;timeout-minutes: 100on the job (healthy runs ~20min);benchmarks/baseline.jsonrefreshed from the last green run (27001035612, June 5) — the April baseline (array_write 3ms vs 3.1–3.4s measured on every June run) would hard-fail every release the moment the gate worked againbinary-sizelibperry_runtime+34.8% vs v0.5.1122 baseline (threshold 15%)Already resolved elsewhere
perry-windows-x86_64,perry-ui-windows): E0433windows_core— fixed by fix(ui-windows): WebView2 COM init + sync-pump use-after-take; unblock crate build (#4835) #4837 (merged 2h after the v0.5.1150 tag);cargo tree --target x86_64-pc-windows-msvcconfirmswindows-core v0.58direct dep.gh release uploadhit a transient GitHub API outage.Validation
cargo test -p perry-runtimearray/sparse suites green incl. newtest_array_sequential_growth_past_dense_threshold_stays_dense(0.09s — dense)test-parity/node-suite/globals/array-index-boundary.ts+array-property-keys.tsbyte-identical tonode --experimental-strip-typescompare.sh --quick --runs 1 --json-out ... --warn-onlyend-to-end: current.json written, comparison runs, REGRESSION detection fires, warn-only honoredAfter merge: cut the next release tag and watch all 19 platform jobs + publish steps + Regression Check go green.