CredentialComposer plugins can return gRPC status errors with meaningful codes (e.g. PermissionDenied, FailedPrecondition). From reading the code, those codes survive through the plugin facade and signing layers, but get replaced with codes.Internal at the agent-facing API boundary in newX509SVID() and mintJWTSVID() in pkg/server/api/svid/v1/service.go.
Would it make sense to preserve status.Code(err) when the signer/composer returns a proper gRPC status, and only fall back to codes.Internal for non-status or codes.Unknown errors?
Pros
- Agents can distinguish policy failures from infrastructure failures and react accordingly (retry vs. don't retry, alert differently)
- RPC metrics and logs reflect the actual cause instead of lumping everything under Internal
Cons / open questions
- Exposing plugin-originated status codes to agents changes the external API contract, is that a compatibility concern?
- Should there be an allowlist of codes that get passed through, rather than forwarding everything the plugin returns?
- Could leaking specific error codes from composer plugins expose information that should stay server-side?
Curious if this direction seems right, or if there's a reason the current codes.Internal behavior is intentional.
CredentialComposer plugins can return gRPC status errors with meaningful codes (e.g.
PermissionDenied,FailedPrecondition). From reading the code, those codes survive through the plugin facade and signing layers, but get replaced withcodes.Internalat the agent-facing API boundary innewX509SVID()andmintJWTSVID()inpkg/server/api/svid/v1/service.go.Would it make sense to preserve
status.Code(err)when the signer/composer returns a proper gRPC status, and only fall back tocodes.Internalfor non-status orcodes.Unknownerrors?Pros
Cons / open questions
Curious if this direction seems right, or if there's a reason the current
codes.Internalbehavior is intentional.