A municipal change-ticket worker receives HTTP 422 Unprocessable Entity from a Cisco configuration API. How should the consumer map that result?
Select an answer to reveal the explanation.
Short Explanation
When the building inspector stamps “rejected,” the permit desk does not file it as “approved.” Map a 422 into a known app outcome—reject the job, mark failed, notify—rather than fake success or leave only a raw stack.
Full Explanation
Professional consumers convert unrecoverable HTTP failures into outcomes the application already understands. When a municipal change-ticket worker receives HTTP 422 Unprocessable Entity from a Cisco configuration API, the payload or semantics were rejected—validation failed, schema mismatched, or business rules forbade the write. Translating that status into a declared app outcome (reject the job, mark the item failed, notify operators) preserves honest ticket state and gives humans a clear next action instead of a mysterious hang.
Pretending the write succeeded so the ticket can close on schedule fails because the network device or controller never accepted the configuration; closing the ticket creates a compliance and rollback gap. Dumping only an uncaught stack trace as the sole contract fails because other services cannot branch on a structured outcome and operators get an opaque crash rather than “validation rejected.” Silently queueuing the identical payload for unlimited automatic retries fails by concept: 422 will keep returning for the same bad body, burning quotas and never converging.
Exam caveat: some platforms use 400 vs 422 interchangeably for validation—both are unrecoverable for that payload until the request is corrected. Do not map 422 into 503-style backoff.
Operational check: confirm the worker’s state machine has an explicit “rejected/failed” terminal for 422, that the Cisco error body is attached to the ticket comment, and that no retry scheduler requeues the identical payload without an operator edit.