Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 46 minutes and 45 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 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 |
Summary
Investigation
The linked Windows release job built binaries with
--target x86_64-pc-windows-msvc, then entered the Python extension step. That extension command omitted--targeton native Windows/macOS, so Cargo used the host output tree (target/release) after the binaries had populatedtarget/<target>/release. On Windows this causes the shared graph to compile again. The binary step also used two separate Cargo invocations forfbuild-cliandfbuild-daemon, so this PR builds those together.Verification
actionlint .github/workflows/template_native_build.ymlcargo check --target x86_64-pc-windows-msvc -p fbuild-cli -p fbuild-daemonwith Rust 1.94.1 MSVC toolchain in an isolated temp target dircargo check --target x86_64-pc-windows-msvc -p fbuild-python --features extension-modulewith Rust 1.94.1 MSVC toolchain in an isolated temp target dir