🐛 Recover and report panics in provider subprocesses#6939
Merged
Conversation
![mondoo-code-review[bot]](https://avatars.githubusercontent.com/in/2834902?s=60&v=4){kind=small}
There was a problem hiding this comment.
Provider subprocess panics are now recovered and reported as errors instead of crashing the process.
Additional findings (file/line not in diff):
- 🟡
providers-sdk/v1/plugin/grpc.go:111—Heartbeatis the onlyGRPCServermethod missing therecoverPanicguard. A panic inHeartbeatwould still crash the provider subprocess. Adddefer recoverPanic("Heartbeat", &err)for consistency.
Contributor
Provider panics (e.g., nil pointer dereferences in resource creation) previously crashed the subprocess silently — the main process only saw a generic gRPC "Unavailable" error with no panic details or stack trace. This adds panic recovery to all provider-side gRPC server methods. Panics are now caught, logged with full stack traces, and returned as gRPC Internal errors so the main process can surface actionable info instead of just "provider crashed". Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Replace magic numbers 13/14 with codes.Internal/codes.Unavailable - Keep full stack trace in log only; user-facing error shows just the panic value (first line) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Only send short panic message over gRPC wire; full stack trace stays in provider-side logs - Guard codes.Internal case with "panic in provider " prefix check so non-panic Internal errors fall through to default handling Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
vjeffrey
force-pushed
the
worktree-providerpanics
branch
from
cd03b06 to
fe426d0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
defer recover) to all provider-side gRPC server methods (GetData,Connect,StoreData, etc.) in the plugin SDKInternalerrors with the panic message + stack tracehandlePluginError) now handles gRPC code 13 (Internal) to surface provider panic details in query results instead of a generic "provider crashed" messageProblem
When a panic occurred in provider code (e.g., nil pointer dereference in AWS/Azure/GCP resource creation), the provider subprocess would crash silently. The main mql process only detected this via gRPC status code 14 (Unavailable), losing all panic details and stack traces. This made debugging provider issues very difficult.
How it works
recoverPanic()helper inproviders-sdk/v1/plugin/grpc.gocatches panics, logs them, and converts them to gRPC Internal errorshandlePluginError()inproviders/runtime.godetects the new Internal error code and treats it as a recoverable error (returnshandled=true), surfacing the panic details in query resultsTest plan
recoverPanic(string panics, nil pointer panics, no-panic case)🤖 Generated with Claude Code