Repository navigation
fix(playground): surface current build failures - #4298
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
⏭️ Performance benchmarks were skippedPerf benchmarks (CodSpeed) are opt-in on pull requests — they no longer run on every push. They always run automatically after merge to To run them on this PR, do any of the following, then push a commit (or re-run CI):
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughLive projects now track build failures by source revision. Build outcomes record or clear failures by revision. Matching failures appear in published diagnostics, while stale failures are suppressed. Runtime status is checked against the requested source revision. ChangesBuild failure diagnostics
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Build as Build outcome
participant LiveProject
participant BexProject
participant Publisher
Build->>LiveProject: Record or clear failure for source revision
LiveProject->>BexProject: Read runtime status for source revision
LiveProject->>Publisher: Publish leased project update with matching diagnostic
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 29bebd0a6e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
29bebd0 to
96a36f8
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@baml_language/crates/bex_project/src/bex_lsp/multi_project/mod.rs`:
- Around line 1315-1335: The send_update_project flow must retain the
source-revision read lease from build_project_update through the failure lookup
and notification publication. Update the relevant source snapshot handling
around send_update_project so concurrent edits cannot publish diagnostics for an
obsolete revision, or atomically reject such snapshots before publication. Add a
deterministic regression test covering an edit racing with a failed rebuild.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: c9ef206e-cc2b-492f-8ca5-890c24542c26
📒 Files selected for processing (1)
baml_language/crates/bex_project/src/bex_lsp/multi_project/mod.rs
Binary size checks passed✅ 7 passed
Generated by |
96a36f8 to
fc7bc6c
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
baml_language/crates/bex_project/src/bex_lsp/multi_project/mod.rs (1)
1308-1335: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winConfirm the playground transport under the source lease is non-blocking here.
send_update_projectstill holds the source read lease throughplayground_sender.send_playground_notification. For the production native sender this is short, but a bounded/contended channel could stallmutate_sourcesor request-lane reads while a UI/webview write is pending. If the sender is kept as an injecteddyn PlaygroundSender, document the transport contract or publish the payload after releasing the lease with the same revision-fencing/rejection recheck.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@baml_language/crates/bex_project/src/bex_lsp/multi_project/mod.rs` around lines 1308 - 1335, The send_update_project method holds the source read guard while calling playground_sender.send_playground_notification, so ensure this transport call is non-blocking under the injected PlaygroundSender contract and document that guarantee; otherwise construct the update and capture its source revision, release both guard and build_failure before publishing, then recheck revision/fencing and reject stale updates before sending.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@baml_language/crates/bex_project/src/bex_lsp/multi_project/mod.rs`:
- Around line 1308-1335: The send_update_project method holds the source read
guard while calling playground_sender.send_playground_notification, so ensure
this transport call is non-blocking under the injected PlaygroundSender contract
and document that guarantee; otherwise construct the update and capture its
source revision, release both guard and build_failure before publishing, then
recheck revision/fencing and reject stale updates before sending.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: d0c4491d-20a6-463c-84d6-f8d24f1690d8
📒 Files selected for processing (2)
baml_language/crates/bex_project/src/bex_lsp/multi_project/mod.rsbaml_language/crates/bex_project/src/project.rs
fc7bc6c to
6c895d0
Compare
6c895d0 to
5f3b5b1
Compare
5f3b5b1 to
3527145
Compare
Fixes B-1003.
User impact
When the compiler cannot prepare a runnable build without producing a normal source diagnostic, the Run tab now shows the failure in its existing compiler-error banner instead of staying indefinitely at “Preparing current build…”. The error is also replayed after a playground reconnect or state request, and disappears as soon as the source revision changes.
Root cause
The rebuild pipeline preserved source diagnostics but discarded the message from
EngineBuildOutcome::Failedafter logging it. The resultingProjectUpdatehadisBexCurrent: falseand no error-severity diagnostics, which the playground correctly interpreted as a transient build window. Because the failed revision could never become current, that transient state never ended.What changed
LiveProject, scoped to its exactSourceRevision.requestStatereplays.PlaygroundSenderimplementations must perform a bounded, synchronous in-process handoff because project snapshots retain revision-fencing guards during publication.Verification
cargo test -p bex_project --lib(60 passed, 1 ignored)cargo clippy -p bex_project --lib -- -D warningscargo check --target wasm32-unknown-unknown -p bridge_wasmcargo fmt --all -- --checkbaml playgroundserver using current playground assets. A deterministic engine-construction failure was introduced only as temporary, uncommitted test instrumentation, used identically against latest canary and this branch, then removed before committing.isBexCurrent: falseand no error diagnostics, while this branch renders the failure in the expanded compiler-error banner.Screenshots
Before — latest canary
After — this PR
Summary by CodeRabbit