What partial completion means

A multi-step workflow can make real progress without reaching its overall completion condition. The process may stop, but the consequences of earlier actions can remain.

For example, a document workflow might:

1. Create a local document.
2. Upload it to a shared repository.
3. Update a tracking record.
4. Notify a reviewer.

If the notification fails, the document may still exist in both locations and the tracking record may already be correct. Restarting every step could create unnecessary copies. Calling the whole workflow “failed” without further explanation conceals useful progress.

Partial completion is therefore broader than a lost confirmation or an uncertain external effect. A workflow can be partially complete with perfectly clear records: three steps finished, one unfinished.

The more difficult case arises when the workflow cannot establish whether a consequential action occurred. That uncertainty needs its own treatment rather than being folded into a general failure state.

Distinguishing unfinished work from uncertain outcomes

A useful recovery model separates at least four conditions:

• Known complete: evidence establishes that an action reached its defined completion condition.
• Known incomplete: evidence establishes that the action has not completed. It may not have started, or it may have stopped before producing its intended result.
• In progress: the action has started and is still being processed, according to the available status information.
• Outcome uncertain: the available evidence does not establish whether the action completed.

These descriptions depend on what “complete” means for the action. Acceptance into a delivery queue is not the same as delivery. Creating a draft is not the same as publishing it. Publishing is not the same as editorial approval.

Missing evidence of completion is not necessarily evidence of non-completion. A connection timeout may establish that the caller did not receive a response. By itself, it does not establish that the receiving service did nothing.

Partial completion is not the same as delay

A delayed workflow may still be progressing normally. A service might return a job identifier that can be checked while processing continues. If earlier steps are finished, the workflow is also partially complete, but the appropriate response may simply be to wait.

By contrast, a lost connection with no usable job identifier may leave the outcome uncertain. The distinction is not how long the action has taken. It is what the system can establish about its present state.

This is one reason network success and task success should be evaluated separately.

An example: publication without a confirmation record

Consider a publishing workflow with three actions:

1. Save an approved article locally.
2. Send a publication request to a content management system.
3. Record the published article’s identifier and URL locally.

The content management system creates the article, but the connection drops before the originating workflow receives the response. The local record contains the saved article and an attempted publication, but no published identifier.

The external effect exists. The local evidence is incomplete.

Two immediate responses would be misleading or risky:

• “Publication failed.” This states more than the available evidence supports.
• “Publish again.” A second request could create a second article.

A more accurate status would be: “The article is saved locally. Publication was attempted, but confirmation was not received. Check the content management system before retrying.”

If a matching publication can be verified, recovery may consist of recording its identifier and continuing—not publishing again. If its existence cannot be established, the workflow may need further inspection or human review.

Evidence that supports recovery

Recovery depends on evidence that remains available after the original process stops. A success message held only in memory is not much help after a crash.

Durable step records and checkpoints

A durable checkpoint records enough information to resume or inspect the work later. Useful records may include:

• A stable workflow identifier.
• The action attempted and the relevant input version.
• When the attempt started.
• A request identifier or idempotency key, where supported.
• The response and external identifier, if received.
• The last verified state and how it was verified.

A record that says “request started” establishes an attempt, not an outcome. A record that says “request accepted” may establish acceptance, not completion. Checkpoints are most useful when their meanings are explicit.

External identifiers and status inspection

A remote job identifier, publication identifier, or transaction reference can provide a direct route back to the receiving system. A status endpoint may then establish whether the action is pending, complete, or rejected.

When no identifier was received, another stable reference attached to the original request may help locate the result. Searching by title alone is usually weaker evidence: titles can repeat, change, or appear in drafts.

Status checks also have limits. A newly created item may not immediately appear in search results or a replicated listing. “Not found” should be interpreted according to the service’s documented behavior, not automatically treated as proof that nothing happened.

Evidence with context

A useful recovery record preserves where an observation came from and when it was made. A saved response, a current status query, and an operator’s visual inspection are different kinds of evidence.

This connects recovery to document provenance and broader workflow state management: later decisions need a reliable account of both the work and the observations made about it.

When retrying is safe—and when it is not

A retry is appropriate when repeating the action is known to be safe, or when evidence establishes that the original action did not produce the relevant effect. Uncertainty alone is not a sufficient reason to repeat a consequential operation.

Reading a status record is generally different from sending another message, charging a payment method, or creating another publication. Recovery should distinguish inspection from actions that change the world.

What idempotency can protect

An idempotent operation can be repeated without producing an additional intended effect. Some services support idempotency keys that associate repeated requests with one logical operation.

Where the service provides that guarantee, retrying with the same key and compatible request data can help avoid duplicate effects. The protection depends on the service’s actual contract, including which operations it covers and how long it retains the key.

What a local record cannot guarantee

A local idempotency record alone cannot close every gap between an external action and the local record of that action.

If the workflow records completion after sending the request, it can stop after the external effect occurs but before the local update. If it records completion before sending, it can stop before the external effect occurs and leave a misleading success record.

Recording an intention before the request is useful. It makes the attempt traceable. But without additional coordination or receiving-service support, that intention record does not prove the external outcome or prevent every duplicate.

A database transaction can make related changes atomic within its supported scope. It does not automatically include an unrelated external service. Claims of “exactly once” behavior need to specify which effects and system boundaries they cover.

Reconciling state before continuing

Reconciliation means comparing available records and observed results to establish a supported account of the current state. It is not simply rerunning the original workflow.

A practical recovery sequence is:

1. Read the last durable checkpoint. Identify completed steps, attempted actions, and missing confirmations.
2. Inspect the relevant system. Use external identifiers, request references, or documented status checks.
3. Verify the match. Confirm that the result belongs to this operation and the intended input version.
4. Record the finding. Preserve the evidence, its source, and any remaining uncertainty.
5. Choose the next action. Continue, wait, retry within established safeguards, compensate, or request review.

If an external result is found, the workflow may only need its local record repaired. If the original request is still processing, waiting may be safer than retrying.

Some effects require compensation rather than a simple restart or rollback. Removing a duplicate publication is a new action with its own consequences; it does not undo notifications or copies that may already exist. Compensation should be authorized and tracked accordingly.

When the evidence remains inconclusive, “requires review” is a legitimate recovery state. Recovery from failed workflow steps should preserve unresolved uncertainty rather than force every case into success or failure.

Reporting partial completion clearly

A useful status report explains what happened and what the reader can safely do next. A single red error banner rarely provides enough information for a multi-step operation.

For the publishing example, a clear report might read:

• Local article: saved.
• Publication request: sent; confirmation not received.
• Published identifier: not yet recorded.
• Next action: check the publishing system before sending another publication request.

Where a workflow mixes independent actions, the report can also identify which work remains safe to continue. An uncertain publication does not necessarily prevent preparing an unrelated local document.

Interfaces should avoid offering a broad “Try again” action when it may repeat completed side effects. More specific actions—such as “Check publication status” or “Retry notification”—make the recovery boundary clearer. This is part of useful interface feedback, not merely error handling.

Designing workflows for recoverable progress

Workflows are easier to recover when their steps have explicit completion conditions, durable records, and defined retry behavior.

Before automating a consequential action, establish:

• What evidence will count as completion.
• How an interrupted attempt can be inspected.
• Whether repetition can create another effect.
• Which unfinished steps can continue independently.
• Who can authorize a retry, correction, or compensating action.

These decisions establish automation boundaries before an interruption makes them difficult to reconstruct.

Partial completion is not always a defect. Many useful workflows proceed through durable stages and pause between them. The important distinction is whether the system can describe its progress honestly and support a safe next step.

The process’s final message is evidence, but it is not the whole state of the work. Recovery should follow what can be established about the existing results—not merely whether the original run reported success.