tests: machine-independent timing bounds and crate-standalone hermeticity - #4499
Conversation
…city Timing-sensitive tests currently encode idle-16-vCPU behavior as correctness: cancellation suites assert sub-second wall-clock bounds, the prof soak bounds a whole run instead of a round, and the webview vitest config sizes its worker pool from availableParallelism(). On larger or busier machines these fail (or in vitest's case, fork-bomb) without any product regression. - sdk_tests cancellation (rust, typescript, java): keep the semantic property (cancellation interrupts the call) but bound it at 5s with the cancelled sleeps raised to 60s, so a regression that ignores cancellation still cannot pass; java also cancels the timed-out future instead of leaking it. - bex_events prof consumer soak: per-round wedge bound (30s) instead of a per-machine total, so a wedged consumer fails fast with the named panic inside the job timeout on any host. - webview vitest.config.ts: cap maxWorkers (overridable via VITEST_MAX_WORKERS), at or above what 16 vCPUs produce naturally. - bridge_cffi header_generation + java sdk setup scripts: stop assuming the crate lives inside a full workspace checkout with a rustup-managed toolchain; behavior is byte-identical in the current layout.
|
@harivansh-afk is attempting to deploy a commit to the Boundary Team on Vercel. A member of the Team first needs to authorize it. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe changes adjust soak-test acknowledgment timing, support configurable CFFI crate paths, extend SDK cancellation test durations, use workspace toolchains for Java bridge builds, and pre-bundle dependencies for VSCode browser tests. ChangesOrphan churn soak timing
CFFI bridge path resolution
SDK cancellation test timing
Java bridge setup
VSCode browser test configuration
Estimated code review effort: 2 (Simple) | ~15 minutes Merge Risk: 🟡 Moderate · up to This PR makes machine-sensitive tests and setup behavior more robust without identifying a product-path regression, but merge readiness is currently moderate because required Rust checks remain incomplete and a profiling test timed out; merge should wait for those checks to pass or for the timeout to be explicitly accepted. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Timing-sensitive tests currently encode idle-16-vCPU behavior as correctness: the cancellation suites assert sub-second wall-clock bounds, the prof soak bounds a whole run instead of a round, and the webview vitest config sizes its worker pool from
availableParallelism(). On larger or busier machines these fail (or in vitest's case, fork-bomb) without any product regression. Found running this repo's CI on 64-vCPU self-hosted runners; every change is a no-op or strictly looser on your 16-vCPU runners, and none can mask a real regression.vitest.config.ts: capmaxWorkers(overridable viaVITEST_MAX_WORKERS), at or above what 16 vCPUs produce naturally - a no-op for your runners, a hard requirement on 64-core ones whereavailableParallelism()-1workerd processes OOM the machine.BAML_BRIDGE_CFFI_DIRenv seam; toolchain pinning delegated to the workspacerust-toolchain.toml). Behavior is byte-identical in the current layout; the java Windows script drops an explicit rustup toolchain dispatch for parity with the unix script.Split out of #4483 so that PR stays new-files-only; merge order between the two does not matter (without this, the non-gating ix preview lanes just flake).
Summary by CodeRabbit
Bug Fixes
Tests
Chores