fix(ide): propagate in-container setup failures instead of panicking#456
Conversation
When an IDE install inside the container failed (e.g. Jupyter on a Node
image with no pip), the inner agent exited non-zero without sending a
structured result, the host received a half-populated Result with a nil
SubstitutionContext, and openIDE nil-derefed on
ContainerWorkspaceFolder.
Three-layer defense:
- Inner agent now sends Result{Error: ...} via the tunnel on setup
failure, so the underlying cause survives the SSH boundary.
- Outer agent surfaces a forwarded result.Error as a non-zero exit.
- Host validates SubstitutionContext and opener guards against nil
Result before dispatching to any per-IDE handler.
Send-failure logs upgraded from Debug to Error and include the original
cause so a failure-on-failure leaves a breadcrumb.
✅ Deploy Preview for devsydev canceled.
|
|
Warning Review limit reached
More reviews will be available in 32 minutes and 44 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, 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 include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
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
Creating a workspace with the Jupyter Notebook IDE on a container without Python (e.g.
vscode-remote-try-node) panicked the CLI:Root cause: the in-container
jupyter installfailed (no pip in a Node image), the inner agent exited non-zero without sending a structured result, the host received a half-populatedResultwith a nilSubstitutionContext, andopenIDEnil-derefed accessingContainerWorkspaceFolder.Three-layer fix:
cmd/agent/container/setup.go— newreportSetupFailuresendsResult{Error: cause}through the tunnel on setup failure (pre-attach or post-attach), so the underlying cause survives the SSH boundary instead of collapsing to a generic SSH exit-code wrapper.cmd/agent/workspace/up.go—up()now surfaces a forwardedresult.Erroras a non-zero process exit. Pre-existing send-failure log upgraded from Debug to Error and now includes the original cause.cmd/up/up.go— host-sideexecuteDevsyUprejects results missingSubstitutionContextwith a clear error, so a future regression won't reachopenIDEwith a half-populated result.pkg/ide/opener/opener.go—validateOpenParamsguards the dispatcher; nilResultorSubstitutionContextproduces a descriptive error naming the IDE before any per-IDE handler runs.After the fix, the same scenario surfaces as:
start workspace: seems like neither pip3 nor pip exists, please make sure to install python correctly— flowing through the existingWriteErrorJSONenvelope to the desktop frontend.Added
TestOpen_NilResultRejectedcovering nilResultand nilSubstitutionContextacross browser (jupyter, openvscode) and desktop (vscode) dispatch paths to pin the original crash.