Recover according to failure class

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Contact read returns 403 with teaching missing_scope contacts:read; alternatives include invalid input,429 or successful empty arrays. Transport/status and business outcomes need structured classification.

Mechanism

Use verified service/SDK types and inner errors for access/input/transient/valid-empty outcomes. Stop identical permission retries, correct schema errors, back off within bounds and preserve no-match success. Unknown classes stay unclassified instead of universal string/status heuristics.

Bad example

Retry 403 ten times, call it no contacts, accept outer 200/inner-error and endlessly retry empty arrays.

Good example

Read teaching 403 scope details and report unmet access without identical retries; resume after authorized correction. Fix schema inputs, bound 429 retries and accept valid empty matches. Inspect outer/inner state, preserve unknown classes/safe checks and omit credentials or fabricated contacts.

Why the change matters

Repetition does not repair permissions/inputs, while valid absence needs no repair. Semantic recovery distinguishes denied, empty and transient states.

Observable expectation

Teaching cases map permission→gap, input→field, rate→bound, ok/[]→no match and outer-success/inner-error→business failure. Inspect categories/limited actions.

No contacts are queried and frozen class names are not current SDK claims.

Limits

Codes vary by service. Writes with transient failures may have unknown effects requiring idempotency/reconciliation, not blind retry just because transient.