Partial Email Account Tasks: Reconcile, Retry, and Recover Without Duplicates

Classify partial, failed, and uncertain states correctly

A partial task has successful output and failed items in the same terminal result. A failed task has no usable completed output according to the task record. An uncertain request occurs when the client cannot tell whether the server accepted it, often because the connection ended before a response arrived.

These states require different actions. Partial needs reconciliation, failed needs cause review, and uncertain needs retrieval or idempotent recovery. Treating all three as retry now is how duplicate tasks and unexplained costs begin.

Preserve successful output before planning a replacement

Retrieve the authoritative task and record requested, successful, failed, provider, final state, credits charged, and credits returned. Route the usable output through the approved result path instead of discarding it because the original target was not reached in full.

The unresolved quantity is requested minus accepted successful results, not necessarily the raw failed count. If the receiving system rejects some completed results, document that separately from MailMaker task failure so product and downstream issues are not blended.

• Source task ID
• Successful provider results
• Task-reported failures
• Downstream rejections
• Credits charged and returned
• Approved unresolved quantity

Recover an uncertain creation request before submitting another

Persist an idempotency key before the first API call. If the client times out, repeat the same logical request with that key or retrieve the associated task according to the API contract. Do not generate a fresh key merely because the first response was lost.

If the system still cannot establish whether a task exists, stop automatic submission and escalate with the key, timestamp, provider, quantity, and correlation ID. A manual check is less expensive than two valid account batches created for one internal request.

Retry by failure class, not by a generic counter

Validation errors require corrected input. Insufficient balance requires a budget decision. A temporary transport or service condition may justify bounded backoff. Provider or policy failures may require stopping rather than retrying. A partial task requires a new, explicitly approved request only for unresolved work.

Set a maximum attempt count and maximum job age in the calling system. When either limit is reached, move the job to a named manual-review queue with enough context to decide without exposing raw credentials.

• Invalid request: correct and reapprove
• Timeout: recover idempotently
• Temporary condition: bounded backoff
• Partial: reconcile then replace unresolved quantity
• Permanent or policy issue: stop and escalate

Close recovery with one explainable record

Link the original task, any replacement task, final accepted output, credit movement, and decision owner. The total across tasks should reconcile to the approved requirement without counting the same result twice.

Update the runbook with the observed cause and the control that will reduce recurrence. Useful changes may include clearer validation, durable idempotency storage, slower polling, a smaller batch size, stronger balance checks, or a more reliable result destination.