feat(launching): detect and surface post-spawn launch failures - #340
feat(launching): detect and surface post-spawn launch failures#340bobtista wants to merge 7 commits into
Conversation
|
Warning Review limit reached
Next review available in: 51 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?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 reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. 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, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
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 |
Code Review SummaryStatus: 3 Issues Found | Recommendation: Address before merge
Overview
Issue Details (click to expand)CRITICAL
Files Reviewed (3 files)
Fix these issues in Kilo Cloud Previous Review Summaries (2 snapshots, latest commit f2eba92)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit f2eba92)Status: 4 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)CRITICAL
WARNING
Files Reviewed (11 files)
Note: The previous review SHA was rebased away, so this pass re-reviewed the full PR diff against current HEAD ( Fix these issues in Kilo Cloud Previous review (commit 163343e)Status: 3 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)CRITICAL
Files Reviewed (11 files)
Note: All identified issues have already been reported by Greptile inline comments. No duplicate issues found. The PR makes significant improvements to post-spawn failure detection but has critical threading and error handling issues that need to be addressed. Reviewed by glm-5.2 · Input: 27.8K · Output: 11.4K · Cached: 251.9K |
…e and sentinel matching
163343e to
f2eba92
Compare
The base branch was changed.
|
Rebased onto
Instead the six commits unique to this branch were replayed onto Verified after rebase: full core suite 1,553 passed, 0 failed. No approvals existed, so nothing was dismissed by the force-push. |
| /// PIDs are recycled: an event held indefinitely could be applied to an unrelated | ||
| /// later launch that happened to receive the same PID. | ||
| /// </remarks> | ||
| private static readonly TimeSpan PendingExitRetention = TimeSpan.FromSeconds(30); |
There was a problem hiding this comment.
WARNING: Pending-exit retention is far larger than the race it covers, so a buffered exit can be applied to a later, unrelated launch that recycles the PID.
PendingExitRetention is 30 s, but the gap it buffers (between StartProcessAsync returning and the launcher updating the placeholder entry with the real PID) is described above as milliseconds. Buffered exits are keyed by PID, and this PR explicitly targets Windows, where PIDs recycle. If a later launch is handed a PID that was recycled within the 30 s window, RegisterLaunchAsync drains the stale exit via TryRemove at line 118 and calls ApplyProcessExit, marking the unrelated (possibly still-running) launch as terminated/failed using the dead process exit code and stderr. A second consequence: a terminated launch is never removed from _activeLaunches, so its lingering PID makes OnProcessExited match the recycled-PID event against it (idempotency then drops it) instead of buffering it for the new launch. Tightening this to ~1-2 s still covers the millisecond race with a large margin while shrinking the recycling exposure by an order of magnitude.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Summary
Detect engine initialization failures both during startup and after a launch has been reported as running, preserving stderr evidence so users receive actionable errors.
Changes
[ggc]mount-failure sentinels and name affected archives.Testing
dotnet test GenHub/GenHub.sln -c Release— 1,461 tests passed.Risks and rollback
The Windows system-modal crash dialog remains an engine-side limitation because the process does not exit while the dialog is open. A crash occurring immediately before a requested Stop may be classified as intentional termination; this tradeoff is documented. Reverting this PR restores the previous fixed-window behavior.
Related issues
Fixes #334
Greptile Summary
This PR expands launch-failure detection and reporting across the process manager, launch registry, and profile UI.
Confidence Score: 4/5
The PR is not yet safe to merge because cancellation can orphan a spawned game, termination failures can suppress later crash reporting, and process-exit callbacks still mutate UI state off the Avalonia thread.
The current process-start path can return failure after spawning without tracking or terminating the process; the termination path leaves its classification marker behind when killing fails or is cancelled; and the exit callback updates observable UI state directly from the process event thread.
Files Needing Attention: GenHub/GenHub/Features/GameProfiles/Infrastructure/GameProcessManager.cs; GenHub/GenHub/Features/GameProfiles/ViewModels/GameProfileLauncherViewModel.cs
Important Files Changed
Sequence Diagram
sequenceDiagram participant UI as Profile Launcher UI participant Launcher as GameLauncher participant Registry as LaunchRegistry participant Manager as GameProcessManager participant Process as Game Process Launcher->>Registry: Register placeholder launch (PID -1) Launcher->>Manager: StartProcessAsync Manager->>Process: Spawn and capture stderr alt Process exits within detection window Process-->>Manager: Exit code and stderr Manager-->>Launcher: Failed startup result else Process survives detection window Manager-->>Launcher: Running process and real PID Launcher->>Registry: Register real PID alt Process exits after launch Process-->>Manager: Exit event Manager->>Registry: Record termination or late failure Manager->>UI: Clear running state and surface failure end endReviews (4): Last reviewed commit: "fix(launching): stop buffered exits reac..." | Re-trigger Greptile
Context used: