⚡ Bolt: Offload synchronous file I/O to spawn_blocking in UI handlers#514
⚡ Bolt: Offload synchronous file I/O to spawn_blocking in UI handlers#514EffortlessSteven wants to merge 1 commit into
Conversation
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
Warning Review limit reached
More reviews will be available in 26 minutes and 19 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ 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 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request moves synchronous file I/O and YAML parsing operations in crates/http-platform/src/ui.rs into tokio::task::spawn_blocking to prevent blocking the Tokio worker thread. It also moves the tokio dependency from dev-dependencies to standard dependencies in Cargo.toml. The review feedback recommends propagating panics from the spawned blocking tasks using .expect(...) instead of swallowing JoinErrors with fallback values, which can hide bugs and cause compilation issues.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| let (status_result, tasks_result, metadata, policy_status, feature_status_content) = | ||
| tokio::task::spawn_blocking(move || { | ||
| let status = load_all_specs(&root); | ||
| let tasks = spec_runtime::load_tasks(&root.join("specs/tasks.yaml")); | ||
| let meta = load_service_metadata(&root.join("specs/service_metadata.yaml")).ok(); | ||
|
|
||
| let policy_path = root.join("target/policy_status.json"); | ||
| let policy = std::fs::read_to_string(policy_path) | ||
| .ok() | ||
| .and_then(|content| serde_json::from_str::<serde_json::Value>(&content).ok()) | ||
| .and_then(|v| v.get("summary").and_then(|s| s.as_str()).map(String::from)) | ||
| .unwrap_or_else(|| "unknown".to_string()); | ||
|
|
||
| let feature_status_path = root.join("docs/feature_status.md"); | ||
| let feature_content = if feature_status_path.exists() { | ||
| std::fs::read_to_string(feature_status_path).ok() | ||
| } else { | ||
| None | ||
| }; | ||
|
|
||
| (status, tasks, meta, policy, feature_content) | ||
| }) | ||
| .await | ||
| .unwrap_or_else(|_| (Err(spec_runtime::SpecError::Internal("spawn_blocking failed".to_string())), Err(spec_runtime::SpecError::Internal("spawn_blocking failed".to_string())), None, "unknown".to_string(), None)); |
There was a problem hiding this comment.
Swallowing JoinError from spawn_blocking using unwrap_or_else can hide panics and bugs in the spawned task, making debugging difficult. Additionally, referencing spec_runtime::SpecError::Internal might cause compilation errors if that variant does not exist. It is more idiomatic and robust to propagate panics by calling .expect("blocking task panicked") on the JoinHandle result.
let (status_result, tasks_result, metadata, policy_status, feature_status_content) =
tokio::task::spawn_blocking(move || {
let status = load_all_specs(&root);
let tasks = spec_runtime::load_tasks(&root.join("specs/tasks.yaml"));
let meta = load_service_metadata(&root.join("specs/service_metadata.yaml")).ok();
let policy_path = root.join("target/policy_status.json");
let policy = std::fs::read_to_string(policy_path)
.ok()
.and_then(|content| serde_json::from_str::<serde_json::Value>(&content).ok())
.and_then(|v| v.get("summary").and_then(|s| s.as_str()).map(String::from))
.unwrap_or_else(|| "unknown".to_string());
let feature_status_path = root.join("docs/feature_status.md");
let feature_content = if feature_status_path.exists() {
std::fs::read_to_string(feature_status_path).ok()
} else {
None
};
(status, tasks, meta, policy, feature_content)
})
.await
.expect("blocking task panicked");| let (metadata, specs_result) = tokio::task::spawn_blocking(move || { | ||
| let meta = load_service_metadata(&root.join("specs/service_metadata.yaml")).ok(); | ||
| let specs = load_all_specs(&root); | ||
| (meta, specs) | ||
| }) | ||
| .await | ||
| .unwrap_or_else(|_| (None, Err(spec_runtime::SpecError::Internal("spawn_blocking failed".to_string())))); |
There was a problem hiding this comment.
Propagating panics from spawn_blocking via .expect("blocking task panicked") is safer and more idiomatic than swallowing the JoinError and returning a potentially invalid SpecError::Internal variant.
| let (metadata, specs_result) = tokio::task::spawn_blocking(move || { | |
| let meta = load_service_metadata(&root.join("specs/service_metadata.yaml")).ok(); | |
| let specs = load_all_specs(&root); | |
| (meta, specs) | |
| }) | |
| .await | |
| .unwrap_or_else(|_| (None, Err(spec_runtime::SpecError::Internal("spawn_blocking failed".to_string())))); | |
| let (metadata, specs_result) = tokio::task::spawn_blocking(move || { | |
| let meta = load_service_metadata(&root.join("specs/service_metadata.yaml")).ok(); | |
| let specs = load_all_specs(&root); | |
| (meta, specs) | |
| }) | |
| .await | |
| .expect("blocking task panicked"); |
| let (metadata, flows_result, tasks_result) = tokio::task::spawn_blocking(move || { | ||
| let meta = load_service_metadata(&root.join("specs/service_metadata.yaml")).ok(); | ||
| let flows = spec_runtime::load_devex_flows(&root.join("specs/devex_flows.yaml")); | ||
| let tasks = spec_runtime::load_tasks(&root.join("specs/tasks.yaml")); | ||
| (meta, flows, tasks) | ||
| }) | ||
| .await | ||
| .unwrap_or_else(|_| (None, Err(spec_runtime::SpecError::Internal("spawn_blocking failed".to_string())), Err(spec_runtime::SpecError::Internal("spawn_blocking failed".to_string())))); |
There was a problem hiding this comment.
Propagating panics from spawn_blocking via .expect("blocking task panicked") is safer and more idiomatic than swallowing the JoinError and returning a potentially invalid SpecError::Internal variant.
| let (metadata, flows_result, tasks_result) = tokio::task::spawn_blocking(move || { | |
| let meta = load_service_metadata(&root.join("specs/service_metadata.yaml")).ok(); | |
| let flows = spec_runtime::load_devex_flows(&root.join("specs/devex_flows.yaml")); | |
| let tasks = spec_runtime::load_tasks(&root.join("specs/tasks.yaml")); | |
| (meta, flows, tasks) | |
| }) | |
| .await | |
| .unwrap_or_else(|_| (None, Err(spec_runtime::SpecError::Internal("spawn_blocking failed".to_string())), Err(spec_runtime::SpecError::Internal("spawn_blocking failed".to_string())))); | |
| let (metadata, flows_result, tasks_result) = tokio::task::spawn_blocking(move || { | |
| let meta = load_service_metadata(&root.join("specs/service_metadata.yaml")).ok(); | |
| let flows = spec_runtime::load_devex_flows(&root.join("specs/devex_flows.yaml")); | |
| let tasks = spec_runtime::load_tasks(&root.join("specs/tasks.yaml")); | |
| (meta, flows, tasks) | |
| }) | |
| .await | |
| .expect("blocking task panicked"); |
| let metadata = tokio::task::spawn_blocking(move || { | ||
| load_service_metadata(&root.join("specs/service_metadata.yaml")).ok() | ||
| }) | ||
| .await | ||
| .unwrap_or(None); |
There was a problem hiding this comment.
Swallowing JoinError with .unwrap_or(None) will silently hide any panics or bugs that occur inside the spawned blocking task. Propagating the panic via .expect("blocking task panicked") is more robust and adheres to the fail-fast principle.
| let metadata = tokio::task::spawn_blocking(move || { | |
| load_service_metadata(&root.join("specs/service_metadata.yaml")).ok() | |
| }) | |
| .await | |
| .unwrap_or(None); | |
| let metadata = tokio::task::spawn_blocking(move || { | |
| load_service_metadata(&root.join("specs/service_metadata.yaml")).ok() | |
| }) | |
| .await | |
| .expect("blocking task panicked"); |
Test Results283 tests 245 ✅ 11m 21s ⏱️ Results for commit 17a0c88. |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_4e0ce62c-3142-42ff-9f66-6b2a228d774b) |
1 participant
💡 What: Refactored the UI page handlers (
dashboard,graph_view,flows_view,coverage_view) incrates/http-platform/src/ui.rsto wrap all synchronous file I/O operations (likestd::fs::read_to_string) and heavy YAML parsing (load_all_specs,load_tasks,load_service_metadata) insidetokio::task::spawn_blocking.🎯 Why: Synchronous operations block the active Tokio worker thread. When handling multiple concurrent requests, blocking a worker thread can cause severe latency spikes and starve other asynchronous tasks on the same runtime. Offloading these to a dedicated blocking thread pool improves overall application responsiveness.
📊 Impact: Prevents thread starvation under load and significantly reduces tail latency for other concurrent HTTP requests processed by the same Axum server instance.
🔬 Measurement: Verify with
cargo test -p http-platformand observe improved tail latencies in high-concurrency benchmarks hitting the UI endpoints alongside other API endpoints.PR created automatically by Jules for task 8647280238410533512 started by @EffortlessSteven
Note
Low Risk
Behavior-preserving concurrency refactor on internal UI routes; main risk is spawn_blocking join/panic handling differing slightly from inline I/O errors.
Overview
Moves synchronous spec loading, filesystem reads, and YAML parsing out of the async Axum UI handlers (
dashboard,graph_view,flows_view,coverage_view) intotokio::task::spawn_blockingclosures so Tokio worker threads stay free under concurrent load.On the dashboard, policy status (
target/policy_status.json) and feature status (docs/feature_status.md) reads are bundled into the same blocking task asload_all_specs/ tasks / metadata. Each handler awaits the blocking task and maps join failures to the same error/empty fallbacks as before.tokiois promoted from dev-dependencies to dependencies onhttp-platformsospawn_blockingis available in library code.Reviewed by Cursor Bugbot for commit 17a0c88. Bugbot is set up for automated code reviews on this repo. Configure here.