| name | recover-stuck-production |
| description | Diagnose and recover a troubled/wedged Interoperability production, following the recover-first, clean-last-resort escalation ladder. Never suggests killAppData without the user's explicit acceptance of persistent business-state loss. |
Recover Stuck Production
No production class name given — discover it from iris_production_status (its name field) in step 1.
No namespace specified — omit namespace to use the server's configured default on every call below.
Escalation ladder — follow IN ORDER, do not skip ahead:
- Call
iris_production_status (with detail: true) to see the current production name and state (Running/Stopped/Suspended/Troubled/NetworkStopped).
- Call
iris_production_summary (cross-namespace, no namespace param) and iris_production_queues to locate stuck or backed-up items — queues that are not draining, items reporting errors.
- For each stuck/errored item, call
iris_production_logs filtered by itemName and/or type: "Error" to understand what is actually wrong.
- Try
iris_production_control action 'recover' FIRST (pass name: "<production>" if known). This attempts to restart a troubled production without touching stored state.
- Re-check status (
iris_production_status) — if the production is now healthy, STOP here; report success.
- Only if still wedged after 'recover', call
iris_production_control action 'clean' — this clears STALE TRANSIENT runtime state (queues, job-status, suspended messages) that 'recover' cannot fix. This is a last resort, not a first response.
- NEVER suggest
killAppData: true on the 'clean' action unless the user has EXPLICITLY and knowingly accepted that it wipes PERSISTENT Ens.AppData business state (HL7 sequence numbers, file/FTP done-file tables — wiping these causes re-ingestion and DUPLICATE messages — and RecordMap/X12 batch/control-number state). If considering it, first explain the consequence to the user IN FULL and require an explicit "yes, I accept the data loss" before passing killAppData: true AND confirm: true together (both are required; this is a deliberate double confirmation gate).
- After any recovery action, re-check
iris_production_status to verify a healthy restart before reporting success.