Partial failure and retry case
Pine Harbor's support lead needs a retry policy for a partially completed request flow.
Run A created PH-81 and failed its notification. Run B timed out during create with no reliable output. Use the provided evidence to choose recovery scope, identity checks, audit requirements and a final duplicate-safe recommendation.
Pine Harbor's request flow writes a list item and then emails its owner. Support sees a failed run and wants to retry it. The record already exists, but the failed notification makes the overall status look incomplete. Repeating every action could create a second business request.
Work through the evidence in sequence. First separate the completed write from the missing email. Then consider a second run whose create action timed out and has an uncertain result. The final recommendation must handle both a confirmed partial completion and an ambiguous write. You are choosing an operational recovery policy, not inventing a new transaction mechanism across connectors. Preserve stable source identity and enough run evidence for the next operator to see what happened and what the repair changed.
The item write completed; the notification still needs recovery.
Treat the completed write and failed notification as separate outcomes.