Skip to content

Add structured failureReason to operation error response - #1934

Draft
vkalapov wants to merge 2 commits into
cloudfoundry:masterfrom
vkalapov:feature/LMCROSSITXSADEPLOY-3718-failure-reason
Draft

vkalapov wants to merge 2 commits into
cloudfoundry:masterfrom
vkalapov:feature/LMCROSSITXSADEPLOY-3718-failure-reason

Conversation

@vkalapov

Copy link
Copy Markdown
Contributor

Description:

Enriches the Operation error response with a machine-readable failureReason
object so API consumers can act on errors programmatically without parsing
free-text messages.

What changes:

  • FailureReason model added: code (enum: CONTENT_VALIDATION_ERROR,
    MODULE_STARTUP_FAILURE, SERVICE_OPERATION_FAILURE,
    CF_API_UNAVAILABLE, QUOTA_EXCEEDED, INTERNAL_ERROR), retryable
    (bool), summary (string).
  • Operation gains a nullable failureReason field.
  • OperationInErrorStateHandler classifies the root-cause exception and
    populates FailureReason before persisting the operation.
  • OperationsHelper extended to carry the failure reason through to the
    response.

Design choices:

  • Classification is conservative: unrecognised exceptions map to
    INTERNAL_ERROR / retryable: false rather than guessing.
  • summary is intentionally short (one sentence) — full detail remains in
    the messages array.

Issue:

LMCROSSITXSADEPLOY-3718

Adds the FailureReason schema (code enum + retryable) and wires
failureReason onto the Operation model and mtarest.yaml.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant