A city IT integration catches an unrecoverable 4xx from a Cisco API inside a helper and returns an empty “success” object so callers keep running. What is the correct design instead?
Select an answer to reveal the explanation.
Short Explanation
Hiding a broken pipe under the sink does not fix the leak—it just floods the basement later. Catching an unrecoverable Cisco API error and faking success hides the failure; propagate it so the caller can stop or compensate.
Full Explanation
Unrecoverable client errors from a Cisco API must remain visible to the next layer. When a city IT integration catches an unrecoverable 4xx inside a helper and returns an empty “success” object, it converts a failed hop into a false happy path. Callers then continue change tickets, inventory syncs, or citizen-facing jobs as if the platform write or read completed. The correct design is to propagate a failure outcome—raise an exception, return a Result err, or pass an explicit failure status—so the next layer can stop, compensate, or notify operators.
Keeping swallowing the status so upstream jobs never pause fails because municipal automation then drifts from real Cisco state while dashboards stay green. Logging nothing and returning null so callers assume the hop completed fails by hiding both the signal and the audit trail. Replacing the failure with a fabricated 200 body that mirrors a prior successful call fails even harder: it invents inventory or config that may no longer exist and poisons idempotent retries.
Exam caveat: mapping a 4xx into a typed domain error is still propagation; only inventing success is wrong. Recoverable paths (refresh-token-then-retry, 429 backoff) can stay inside the helper if they eventually surface failure when exhausted.
Operational check: inject a forced 4xx in a staging helper and confirm the ticket worker marks failed (or throws) rather than closing as success, and that error logs retain the Cisco status and body snippet for the NOC.