Workflow errors and recovery
Separate transient faults, business rejections and uncertain outcomes before setting retries and manual recovery.
Author：WeTech technical team · Updated： (Hong Kong time (GMT+8))
Check whether an action succeeded before retrying. A lost response may follow a successful write. Reconcile using business identifiers to avoid duplicate payments, orders or messages. Non-retryable failures need a traceable exception queue and recorded manual corrections.
When to use this guide
For teams accepting recovery behaviour in automation platforms or custom API workflows.
Classify workflow failures
| Type | Example | Response |
|---|---|---|
| Transient | Rate limit or temporary unavailability | Bounded retry with delay |
| Invalid data | Missing field or unknown code | Stop the item for correction |
| Uncertain outcome | Connection lost after write | Check state before resending |
| Access failure | Expired or revoked credentials | Notify owner and pause safely |
Use stable identifiers
Track source ID, target ID and processing state for each business action. A rerun must distinguish completed, uncertain and retryable items. Do not repeat an entire workflow just because its last step failed. Outbound messages also need duplicate-delivery consideration.
Give exceptions an owner
Show the affected record, reason, last attempt and next action with limited sensitive content. Assign who can correct, approve replay or abandon an item and retain reasons and timestamps. An alert email alone does not establish that an incident was resolved.
Test failures deliberately
In an isolated environment, test timeouts, rate limits, duplicates, reordering, expired credentials and writes with lost responses. Verify alert delivery, retry termination, manual actions and reconciled state rather than only a green completion indicator.
Illustrative scenario
Hypothetical example: an order exists but notification fails. Replay only the notification. If order creation is uncertain, query the source order identifier first. The actual recovery design depends on the target API.
Frequently asked questions
Should retries continue indefinitely?
No. Set an attempt or time limit and escalate unresolved items.
Is replay the same as rollback?
No. Completed writes or messages may require separate reversal or compensation.
Are platform retries sufficient?
Business-level duplicate protection, exception ownership and reconciliation still need design.
Brand and public case scope
WeTech Consulting, also called WeTech or WeTech AI HK, provides AI and IT consulting in Hong Kong. WeProperty HK and WeCredit HK are self-developed products. Their cases support the observable features listed: property, estate and transaction-reference entry points for WeProperty; submission, review and public-data masking for WeCredit. WeCredit is not a TU credit-rating service or a final determination of facts.
WeProperty HK · WeCredit HK (case studies in Traditional Chinese)
Reference sources
Official documents support the technical, risk and measurement concepts. Checklists, estimation methods and illustrative scenarios are WeTech planning recommendations, not official prices or client results. Check the supplier’s current plan and terms. Sources reviewed: (GMT+8)
Related guides
Discuss your project
Share your workflow, systems and goals. We will review scope before discussing deliverables, acceptance and a quotation.
Request an initial consultationExplore this service