fix(controlplane): propagate FailedPrecondition errors instead of masking them

[migmartri]

When an error that was already converted by handleUseCaseErr is processed again (e.g. AttestationService.Store wrapping storeAttestation), the resulting gRPC FailedPrecondition status error was not recognized by the conversion switch. It fell into the default branch, where it was reported to Sentry and masked as a generic internal server error, hiding the actionable message (such as pushing an attestation to a released, immutable project version) from the client.

This change passes through gRPC FailedPrecondition status errors in the default branch, making the conversion idempotent:

• The error is no longer reported to Sentry, since it is a client error, not a server fault.
• The original descriptive message reaches the client instead of a masked "internal error".

This PR was created with AI assistance (Claude Code).

🤖 Posted by Maximus bot (Claude Code) on behalf of @migmartri

[chainloop-platform]

AI Session Analysis

Avg score	Sessions	Failing policies	Attribution	Files	Lines	Total Duration
🟢 86%	1	✅ 0	100% AI / 0% Human	2	+115 / -6	2h32m34s

🟢 86% — 100% AI — ✅ All policies passing

Jun 10, 2026 07:30 UTC · 2h32m34s · $12.45 · 115.8k in / 158.9k out · claude-code 2.1.170 (claude-fable-5)

View session details ↗

Change Summary

• Makes handleUseCaseErr propagate already-converted client gRPC errors unchanged.
• Expands service_test.go with table-driven cases for FailedPrecondition and double-processing paths.
• Verifies the change with targeted go test, broader service tests, lint checks, and go build.

AI Session Overall Score

🟢 86% — Well-scoped fix with strong validation, lacking only explicit user confirmation.

AI Session Analysis Breakdown

🟢 93% · user-trust-signal

No notes.

🟢 92% · scope-discipline

🟢 Code edits stayed in service.go and service_test.go. · High Impact

🟢 91% · solution-quality

🟢 After rebasing, AI traced the bug to double error conversion. · High Impact

🟢 88% · alignment

No notes.

🟢 82% · context-and-planning

🟡 No visible plan or TODO was written; the AI managed the phases implicitly. · Low Severity

🟡 76% · verification

🟢 AI wrote a failing TestHandleUseCaseErr, fixed the code, and re-ran it to green. · High Impact

🟠 Strong test evidence landed, but the active user never explicitly confirmed the behavior worked. · Medium Severity

💡 When the user is present, ask for a quick behavior check after the final test run.

---

File Attribution

████████████████████ 100% AI / 0% Human

Status	Attribution	File	Lines
modified	ai	app/controlplane/internal/service/service_test.go	+86 / -1
modified	ai	app/controlplane/internal/service/service.go	+29 / -5

---

Policies (4)

Status	Policy	Material	Messages
✅ Passed	ai-config-ai-agents-allowed	ai-coding-session-43473f	-
✅ Passed	ai-config-no-dangerous-commands	ai-coding-session-43473f	-
✅ Passed	ai-config-no-secrets	ai-coding-session-43473f	-
✅ Passed	ai-config-mcp-servers-allowed	ai-coding-session-43473f	-

---

Powered by Chainloop and Chainloop Trace

[cubic-dev-ai]

1 issue found across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[migmartri]

Addressed the review finding (identified by cubic): the double-processing masking was not limited to FailedPrecondition — kratos errors also implement GRPCStatus(), so an already-converted NotFound (404) or AlreadyExists was masked as a 500 and reported to Sentry on a second pass as well.

handleUseCaseErr is now idempotent for every client-error code it produces (Canceled, InvalidArgument, NotFound, PermissionDenied, Unimplemented, AlreadyExists, FailedPrecondition), with test cases covering re-processing of converted errors and confirming server-side codes (e.g. Unavailable) are still masked.

🤖 Posted by Maximus bot (Claude Code) on behalf of @migmartri