-
Notifications
You must be signed in to change notification settings - Fork 0
[Security] Make unexpected application failures safe across API, persisted runs, MCP, and CLI #2351
Copy link
Copy link
Open
Labels
Priority IIThe active direction's next tranche: wedge capabilities, significant defects, near-term hardening.The active direction's next tranche: wedge capabilities, significant defects, near-term hardening.backendPrimary implementation impact in .NET API/domain/application/infrastructure.Primary implementation impact in .NET API/domain/application/infrastructure.hardeningReliability, safety, operability, and production-readiness improvements.Reliability, safety, operability, and production-readiness improvements.securityAuthentication, authorization, data protection, abuse prevention, and compliance-related changes.Authentication, authorization, data protection, abuse prevention, and compliance-related changes.testingTest coverage, harnesses, regression prevention, and verification pipeline work.Test coverage, harnesses, regression prevention, and verification pipeline work.
Description
Activity
Metadata
Metadata
Assignees
Labels
Priority IIThe active direction's next tranche: wedge capabilities, significant defects, near-term hardening.The active direction's next tranche: wedge capabilities, significant defects, near-term hardening.backendPrimary implementation impact in .NET API/domain/application/infrastructure.Primary implementation impact in .NET API/domain/application/infrastructure.hardeningReliability, safety, operability, and production-readiness improvements.Reliability, safety, operability, and production-readiness improvements.securityAuthentication, authorization, data protection, abuse prevention, and compliance-related changes.Authentication, authorization, data protection, abuse prevention, and compliance-related changes.testingTest coverage, harnesses, regression prevention, and verification pipeline work.Test coverage, harnesses, regression prevention, and verification pipeline work.
Projects
- StatusShow more project fieldsReview
Problem
Taskdeck has good top-level protection:
UnhandledExceptionMiddlewareandResultExtensionsalready return a generic body for unhandled or ordinary HTTPUnexpectedErrorfailures. The remaining boundary is fragmented application catches that copy unknownException.Messageinto persisted run state, multi-status/batch receipts, provider health, MCP/CLI results, or non-standard response paths before the top-level mapper can protect them.Confirmed examples include
AgentRuntime.MarkFailed,OpsCliServicecommand-run state,AutomationExecutorServicebatch receipts (#2281), provider-health details (#2213), database I/O failures mapped as publicInvalidOperation, and several import/planner paths. The supplied CSV also contains benign logging and deliberateDomainException/validation messages, so it is an inventory input rather than a zero-false-positive gate.Refs #2349, #2281, and #2213.
Direction
Build on the existing request correlation and HTTP error boundary. Classify expected domain/validation/provider failures explicitly; log unknown exceptions once with the exception object and the existing bounded request/trace reference; expose or persist only a stable error code, safe retry/fallback guidance, and that reference where appropriate.
Do not add a second unrelated correlation scheme or make UI behavior depend on prose.
Acceptance
X-Request-Id/trace context, and are not double-logged by every layer.DomainException, validation, parse, conflict, quota, and safe provider failures retain useful stable messages.Verification
Use synthetic exceptions containing a secret-like token, Windows path, SQLite constraint, and provider URL. Prove the response/persisted record is safe and the protected log carries the same reference and full exception. Add regressions for a deliberate domain message and a parse/validation message.
Non-goals
No wholesale
Resultrewrite, no blanket replacement of everyex.Message, and no suppression of exceptions from protected logs.Supplied patch disposition
0002-centralize-public-unexpected-errors-pilot.patchapplies cleanly but is not merge-ready. It duplicates current correlation/error infrastructure, proves sanitization only with aNullLogger, and does not cover the non-standard surfaces that motivate this issue. Its database wording can inform a later small pilot.