Why does an Azure Durable Functions orchestration appear to run the same code twice without necessarily sending the same payment twice? Translating durable orchestration documentation requires a careful distinction between replaying an orchestrator’s history and executing external work in an activity. Without that distinction, a multilingual tutorial can mislead readers about duplicates, timers, retries, failure and recovery.
This practical, world-facing Azure Durable Functions localization guide explains orchestrator functions, activity functions, client functions, instance identifiers, event-sourced history, deterministic replay, external events, durable timers, fan-out/fan-in, retries, sub-orchestrations and operational status. It is for technical translators, platform engineers, multilingual educators, international support teams and software writers who need reliable explanatory language rather than word-for-word imitation.
Consider a fictional international education publisher producing verified course certificates. One orchestration starts, calls an activity to generate a document, waits for an external approval event and eventually publishes the record. The worker process restarts between approval and publication. The orchestrator may replay earlier steps to rebuild its state, but a completed activity result is obtained from recorded history rather than automatically executing the activity again merely because the orchestrator code was replayed. The translator must keep those boundaries visible.
Quick answer: replay is not the same as repeating external work
Azure Durable Functions helps Azure Functions coordinate stateful and long-running work. Orchestrators record durable progress through an execution history and can be replayed after suspension or failure. Orchestrator code therefore needs deterministic behavior, and external effects should be performed in activity functions rather than directly in orchestrator code. External events can be delivered more than once, so stable event identifiers and deduplication are essential. A completed orchestrator, a completed activity and a customer-visible result are related but distinct claims.
A fictional multilingual publisher: what the instance actually did
A fictional learner requests a multilingual achievement certificate. An HTTP client function starts an orchestration using an instance ID, an activity generates a PDF and another activity requests reviewer approval. The orchestration waits on an external event. Before that event arrives, the function host restarts. Durable history allows the orchestrator to reconstruct earlier decisions; the PDF-generation activity’s recorded result is reused during replay. A later approval event may be delivered more than once, so the application uses a stable approval ID. The public certificate status changes only after the issuer verifies the final stored artifact.
The Azure Durable Functions terminology field guide
1. Durable Functions
Azure Durable Functions is an extension of Azure Functions for writing stateful orchestrations that coordinate activities and survive certain process interruptions.
Translation risk: Do not translate durable as an unconditional guarantee that every external side effect completed exactly once.
Evidence to check: Read orchestration status alongside the activity and external-system records.
2. Orchestrator function
An orchestrator describes the sequence of durable tasks, conditions, waits and exception-handling decisions in a workflow.
Translation risk: Do not present the orchestrator itself as a place for unrestricted network or filesystem side effects.
Evidence to check: Review code constraints and the scheduled activity boundaries.
3. Activity function
An activity performs work outside the orchestrator, such as a web request, file operation or database update.
Translation risk: Do not infer that activity invocation means its external result is fully durable in every dependent system.
Evidence to check: Check the activity’s completion or failure history and the target service record.
4. Client function
A client function can start, query, raise events for or manage orchestration instances through supported APIs.
Translation risk: Do not confuse request accepted by the client with orchestration completed.
Evidence to check: Record the returned instance identifier and query its status.
5. Orchestration instance
An instance represents one logical orchestration with an identifier and lifecycle state.
Translation risk: Do not call the definition’s name an instance identifier in troubleshooting steps.
Evidence to check: Verify instance ID, created time, updated time and status.
6. Instance ID
An instance ID selects the orchestration to query or signal; it is operationally meaningful and may be application-defined.
Translation risk: Do not translate, reformat or accidentally reuse identifiers in runnable instructions.
Evidence to check: Compare the ID sent by clients with the instance currently running.
7. Runtime status
Runtime status describes execution state, such as pending, running, completed, failed or terminated, depending on the API.
Translation risk: Do not translate running as certificate issued or failed as all side effects undone.
Evidence to check: Read status with timestamps and external evidence.
8. Event sourcing
The framework records a history of decisions and results that supports reliable reconstruction after interruption.
Translation risk: Do not localize event history as a record of every physical external action necessarily occurring exactly once.
Evidence to check: Distinguish events describing scheduling, completion and replay.
9. Execution history
The persisted history contains orchestration events used to restore logical state as the code is rerun.
Translation risk: Do not suggest history is merely decorative diagnostic text that can be discarded without implications.
Evidence to check: Check storage and retention behavior for the configured provider.
10. Replay
Replay re-executes orchestrator logic against existing event history to rebuild prior state.
Translation risk: Do not say replay necessarily reruns every previously completed activity side effect.
Evidence to check: Inspect the record of completed activities and newly scheduled work.
11. Determinism
Orchestrator code should take the same logical decisions when driven by the same recorded history.
Translation risk: Do not translate a replay constraint as a general ban on all randomness anywhere in the application.
Evidence to check: Keep nondeterministic I/O within appropriately scheduled activities.
12. Nondeterministic code
Reading uncontrolled wall-clock time, fresh randomness or changing external state inside an orchestrator can undermine replay.
Translation risk: Do not teach readers to use ordinary clock or network calls as if they were replay-safe.
Evidence to check: Use framework-provided deterministic alternatives or activities.
13. Orchestration context
The context exposes durable orchestration APIs for scheduling tasks, timers and events.
Translation risk: Do not change method names across programming-language examples.
Evidence to check: Check SDK and language-specific signatures.
14. Replay-safe logging
Logging in code that replays can duplicate diagnostic lines unless replay-awareness is applied.
Translation risk: Do not interpret duplicated orchestrator log statements as proof that activities ran twice.
Evidence to check: Correlate logs with activity history and replay markers.
15. Current orchestration time
Replay-safe time APIs represent the orchestration’s logical time and preserve determinism.
Translation risk: Do not substitute an ordinary system-clock call into replay-sensitive sample code.
Evidence to check: Verify the SDK’s time API for the chosen language.
16. Durable timer
A durable timer represents a scheduled wake-up that survives orchestration unloading and compatible restarts.
Translation risk: Do not translate timer scheduled as reminder delivered or timed action completed.
Evidence to check: Inspect timer scheduling, firing and subsequent activity outcome.
17. Timer expiration
A timer firing resumes a waiting orchestration but does not itself imply that an external task succeeded.
Translation risk: Do not translate wait completed as approved or paid.
Evidence to check: Check what decision follows the timer.
18. External event
An external event can carry application data to a running orchestration instance.
Translation risk: Do not assume the event has exactly-once delivery semantics.
Evidence to check: Use a stable event ID and evaluate duplicates safely.
19. Wait for external event
The orchestrator can wait asynchronously for a matching event name and process its data when available.
Translation risk: Do not translate waiting as a rejected request or a successful approval.
Evidence to check: Check event name, instance identity and the event payload.
20. Raise event
A client can send an event to a named orchestration instance through the relevant Durable Functions API.
Translation risk: Do not treat a successful send request as proof that the waiting logic already completed.
Evidence to check: Trace the event to the intended instance and history.
21. Event name
The event name is an exact routing value that must agree between sender and waiter.
Translation risk: Do not translate an event name inside executable code unless all participating components are intentionally updated.
Evidence to check: Compare the literal names in both locations.
22. Event payload
The event payload carries JSON-serializable data provided by an external sender.
Translation risk: Do not turn unvalidated payload values into trusted authorization decisions.
Evidence to check: Validate schema, sender and stable event identifier.
23. At-least-once event delivery
Under some failures or restarts, a logically repeated external event can be observed more than once.
Translation risk: Do not promise a single human click produces exactly one event handler effect.
Evidence to check: Implement deduplication for event IDs.
24. Idempotent activity
An activity designed for duplicate attempts can avoid creating a second business effect for the same request key.
Translation risk: Do not translate retry safe as intrinsically safe for every remote API.
Evidence to check: Check domain-specific deduplication and output state.
25. Activity retry
Supported retry options can schedule another activity attempt after eligible failures.
Translation risk: Do not equate retry scheduled with successful recovery or no duplicate effect.
Evidence to check: Inspect retry policy and target operation semantics.
26. Task failure
An activity can fail and surface an exception to the orchestrator for handling.
Translation risk: Do not translate activity failure as the entire orchestration failed unless no handler recovers it.
Evidence to check: Read the exception path and final instance status.
27. Sub-orchestration
An orchestrator may call another orchestration to structure larger jobs.
Translation risk: Do not assume every sub-orchestration shares a single identifier or result state with its parent.
Evidence to check: Trace parent-child relationships and failures.
28. Fan-out/fan-in
The orchestration can schedule multiple activities and wait for their results before continuing.
Translation risk: Do not imply all tasks are sequential or that partial results establish overall success.
Evidence to check: Check completion and exception behavior across all branches.
29. Task list
A task list can represent pending durable operations and their eventual results.
Translation risk: Do not translate a collection of scheduled tasks as finished outputs.
Evidence to check: Confirm await or join conditions.
30. Compensation
A compensating action attempts to counteract earlier effects when exact rollback is unavailable.
Translation risk: Do not call compensation a database transaction rollback unless that is what the remote system guarantees.
Evidence to check: Verify each compensating activity and its success state.
31. ContinueAsNew
A long-running orchestration may restart as a new execution with new input while retaining a logical instance continuity pattern.
Translation risk: Do not translate it as a new customer order automatically created.
Evidence to check: Check input continuity, history reset behavior and business identifiers.
32. Custom status
An orchestrator can expose an application-defined progress value for monitoring clients.
Translation risk: Do not equate custom status with the platform’s runtime status.
Evidence to check: Display both labels clearly when needed.
33. Terminate
A client can request termination of an orchestration instance in the supported API.
Translation risk: Do not claim termination reverses all already completed external transactions.
Evidence to check: Reconcile activities that have executed and any outstanding side effects.
34. Purge history
Management operations can remove stored orchestration instance history under supported conditions.
Translation risk: Do not translate purge as deletion of external files or payments.
Evidence to check: Confirm which storage objects and artifacts are actually affected.
35. Storage provider
A configured durable state backend persists history and scheduling information.
Translation risk: Do not assume identical scaling, retention or diagnostics across providers.
Evidence to check: Check the selected storage provider and application configuration.
36. Task hub
A task hub is an organizational boundary for orchestration tracking and messaging infrastructure.
Translation risk: Do not treat a task hub as a customer account or a physical processing machine.
Evidence to check: Compare the configured hub name and environment.
37. Function host
The Azure Functions runtime hosts orchestrator and activity execution and can restart or scale.
Translation risk: Do not equate one host restart with a fresh business transaction.
Evidence to check: Use durable history and activity result evidence.
38. Checkpoint
The runtime persists certain progress decisions so the orchestration can resume after interruption.
Translation risk: Do not call every source-code line a durable checkpoint.
Evidence to check: Inspect event history for scheduled and completed durable actions.
39. Orchestration suspension
An orchestration can be unloaded while awaiting durable work and later resumed.
Translation risk: Do not describe suspended in memory as data lost.
Evidence to check: Check persistent runtime status and next wake-up condition.
40. Timeout pattern
Combining a durable timer with an external event can produce an approval deadline or escalation path.
Translation risk: Do not translate timeout as an explicit rejection by the approver.
Evidence to check: Distinguish no response from a negative response.
41. Cancellation token
Cancellation behavior in orchestration code is represented through SDK-specific supported APIs.
Translation risk: Do not assume a cancellation request stops every remote activity instantly.
Evidence to check: Check the actual exception and final side-effect state.
42. Entity function
Durable entities support stateful objects and operations with semantics distinct from an orchestration instance.
Translation risk: Do not blur durable entity signals, calls and orchestrator events into one word.
Evidence to check: Read the relevant Durable Entities API separately.
43. Orchestration versioning
Code changes can affect replay compatibility for instances still using prior history.
Translation risk: Do not promise that deploying new code leaves every in-flight instance unaffected.
Evidence to check: Review migration and versioning guidance before rollout.
44. History replay test
A replay test checks whether a code version can reproduce decisions from a representative history.
Translation risk: Do not treat passing unit tests alone as a guarantee of migration safety.
Evidence to check: Use real-shaped histories and deterministic test inputs.
45. HTTP starter
An HTTP-triggered client function can start an orchestration and return management endpoints.
Translation risk: Do not translate the starter’s success response as the long-running operation’s result.
Evidence to check: Use status-query or wait-for-completion mechanisms.
46. Status query URI
A management endpoint can provide later status information for an instance.
Translation risk: Do not present the URL itself as a confirmation of completion.
Evidence to check: Fetch and interpret the latest runtime status.
47. Polling status
Clients may periodically ask whether an orchestration has completed or failed.
Translation risk: Do not confuse a successful HTTP polling request with orchestration success.
Evidence to check: Read the returned runtime status and output or failure fields.
48. External approval
An application-specific approval message might be carried by an external event.
Translation risk: Do not infer the sender is authorized merely because an event name matches.
Evidence to check: Verify signer, authorization and approval provenance.
49. Duplicate approval
Two copies of the same approval event may arrive due to retries or client behavior.
Translation risk: Do not count them as two independent approvals.
Evidence to check: Compare event IDs and enforce business rules.
50. Audit trail
History and application logs can support reconstruction of scheduling, results and human decisions.
Translation risk: Do not present logs as permanent legal records without retention and access controls.
Evidence to check: Check storage policy, redaction and authorization.
51. Sensitive input
Inputs and activity outputs may become durable history or diagnostics depending on configuration.
Translation risk: Do not embed learner identities or secrets in reusable examples.
Evidence to check: Use synthetic data and review logging protections.
52. Language-specific SDK
C#, Python, JavaScript and Java examples use different API surfaces and orchestration syntax.
Translation risk: Do not paste one language’s method name into another language’s code block.
Evidence to check: Validate against the SDK version actually described.
53. End-to-end completion
The orchestration can reach a terminal status while an external user-facing artifact requires separate checks.
Translation risk: Do not equate platform completion with business acceptance or document receipt.
Evidence to check: Verify artifact, identity, review and notification outcomes.
Twelve realistic failure narratives and reader-safe explanations
1. A worker process restarts after generating a PDF
The PDF activity previously completed and its result was recorded before the orchestrator resumed. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: A translated incident note says the restarted orchestrator generated a second PDF automatically. A more defensible explanation is: Explain that orchestrator replay reconstructs state using recorded activity results, while new activity attempts depend on scheduling and retry behavior. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Check activity IDs, history events and the external file store. When those records do not exist, preserve the unknown outcome instead of inventing completion.
2. The orchestrator writes to a database directly
An example places uncontrolled database I/O in replay-sensitive orchestrator code. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: A translator describes that design as the ordinary recommended Durable Functions pattern. A more defensible explanation is: Explain why external I/O belongs in activity functions to prevent replay-caused surprises. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Review deterministic-code constraints and the activity boundary. When those records do not exist, preserve the unknown outcome instead of inventing completion.
3. Two identical approval events arrive
An external system resends the same event after a network timeout. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: The translated public record counts the duplicate as two separate reviewers approving the request. A more defensible explanation is: State that the event may be redelivered and approvals require deduplication by stable event identifier. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Compare event IDs, sender identity and business rules. When those records do not exist, preserve the unknown outcome instead of inventing completion.
4. A durable timer wakes the process
The deadline fires while the reviewer still has not approved the certificate. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: A localized interface describes the reviewer as having rejected the certificate. A more defensible explanation is: Write that the approval window expired without a decision, triggering an escalation path. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Check the timer fire time and any approval event history. When those records do not exist, preserve the unknown outcome instead of inventing completion.
5. A client starts an orchestration
An HTTP starter returns an instance ID and management links. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: The translated API response promises the final report is already ready to download. A more defensible explanation is: Explain that a start response identifies a running or pending instance whose status must be queried later. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Call the status endpoint and inspect output. When those records do not exist, preserve the unknown outcome instead of inventing completion.
6. An activity is retried after a timeout
A provider may have processed the first operation before the client timed out. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: A translated runbook says retry always guarantees one external side effect. A more defensible explanation is: Explain that repeat attempts may occur and the remote operation needs an idempotency key. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Inspect provider transaction IDs and activity retry history. When those records do not exist, preserve the unknown outcome instead of inventing completion.
7. A fan-out job has one failed branch
Nine files were processed and the tenth activity returned an exception. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: The translated status says all ten documents were verified because most tasks succeeded. A more defensible explanation is: Distinguish completed branches from the failed branch and any partial-aggregation policy. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Check each activity result before announcing group completion. When those records do not exist, preserve the unknown outcome instead of inventing completion.
8. A sub-orchestration fails
A child orchestration throws while the parent catches the failure and selects a fallback route. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: The translated alert incorrectly declares that the parent instance necessarily failed. A more defensible explanation is: Explain the child’s failure and the parent’s actual recovery decision separately. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Inspect parent and child instance status. When those records do not exist, preserve the unknown outcome instead of inventing completion.
9. The application uses custom progress
The orchestrator sets a custom status such as awaiting-review while its runtime status remains Running. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: A translator replaces runtime status with the custom label and loses the technical state. A more defensible explanation is: Show both the platform lifecycle and the application-level stage. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Read both fields from the status response. When those records do not exist, preserve the unknown outcome instead of inventing completion.
10. An administrator terminates an instance
The orchestration is terminated after an external email was already sent. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: The localized confirmation says the email was automatically recalled. A more defensible explanation is: State that orchestration termination does not retroactively undo an external send. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Reconcile delivery logs and any compensating procedure. When those records do not exist, preserve the unknown outcome instead of inventing completion.
11. An instance uses ContinueAsNew
A recurring job continues with updated input and refreshed history. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: The translated report counts each continuation as an unrelated customer order. A more defensible explanation is: Explain the logical continuity and the technical history transition distinctly. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Check business key, instance ID semantics and continuation input. When those records do not exist, preserve the unknown outcome instead of inventing completion.
12. A new deployment changes orchestrator code
An in-flight instance has history created by an earlier implementation. Consider the events visible in the durable history and the separate evidence available from external systems. Neither a replayed line of code nor one successful log entry proves every stage of a business process succeeded.
A misleading translation would say: The translation promises every old instance will follow new branching code without compatibility checks. A more defensible explanation is: Explain that deterministic replay compatibility and versioning must be assessed. This wording changes how a support agent, reviewer or engineer responds to the incident, particularly when duplication or unrecoverable side effects are possible.
Verification should include: Test replay with representative old histories before release. When those records do not exist, preserve the unknown outcome instead of inventing completion.
The twelve-step professional translation and verification process
Step 1: Identify the audience and operating claim
Determine whether readers need an introductory explanation, runnable C# or Python code, support troubleshooting or an architecture reference. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
Keep code literal where required and translate only the surrounding meaning. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 2: Draw the orchestration boundary
Map client entry, orchestrator decisions, activities, external events, timers and final outputs. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
This makes it harder to mistake orchestrator replay for repeating every physical action. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 3: Separate runtime and custom status
Write a small status dictionary showing the platform state and application progress side by side. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
A completed platform state is not automatically evidence of successful customer receipt. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 4: Document deterministic decisions
Locate time, randomness, network calls and mutable environment values in the example code. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
Replace replay-unsafe examples with framework-supported APIs or activities. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 5: Audit every external effect
Give every payment, PDF, mail or database write a stable business key and a verification method. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
Idempotency is an application property, not a magic promise attached to replay. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 6: Test duplicate events
Deliver the same approval event twice in a safe environment and inspect the resulting state. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
The translation should explain deduplication, not claim duplicates are impossible. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 7: Test timer versus approval
Exercise both the event-first and timer-first paths and describe which decision wins. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
Waiting, expiry, denial and success must remain separate words. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 8: Check retries and failures
Simulate timeouts, application exceptions and partial fan-out failures without real customer data. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
Readers need to know when retry is safe and when reconciliation is required. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 9: Trace child workflows
Inspect parent and sub-orchestration outcomes, plus ContinueAsNew when applicable. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
One instance’s status should not silently replace another’s. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 10: Account for replay logging
Identify duplicate log lines caused by orchestrator replay and compare them with activity history. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
Do not count log entries as unique activity executions. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 11: Protect stored data
Use synthetic payloads, remove secrets and explain limits of audit retention and history access. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
A world-facing article should not teach readers to expose credentials in histories. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Step 12: Run a bilingual release test
Have a technical reviewer execute the translated example while an editor checks whether conditional claims survived translation. Keep the example’s runtime version, programming language and business goal visible. A term may have a valid everyday translation yet a narrower technical meaning inside this orchestration.
Publish only when the words guide the same operational decision as the source. Compare the translated sentence with a safe execution trace. If a reader might perform a duplicated write, misread a status or wait for the wrong event, revise the sentence before release.
Practical reading exercises: correct the claim before translating it
Exercise 1: A worker process restarts after generating a PDF
In this teaching scenario, The PDF activity previously completed and its result was recorded before the orchestrator resumed. The draft English sentence is overly strong: A translated incident note says the restarted orchestrator generated a second PDF automatically. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: Explain that orchestrator replay reconstructs state using recorded activity results, while new activity attempts depend on scheduling and retry behavior. To review the translation, perform this check: Check activity IDs, history events and the external file store. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 2: The orchestrator writes to a database directly
In this teaching scenario, An example places uncontrolled database I/O in replay-sensitive orchestrator code. The draft English sentence is overly strong: A translator describes that design as the ordinary recommended Durable Functions pattern. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: Explain why external I/O belongs in activity functions to prevent replay-caused surprises. To review the translation, perform this check: Review deterministic-code constraints and the activity boundary. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 3: Two identical approval events arrive
In this teaching scenario, An external system resends the same event after a network timeout. The draft English sentence is overly strong: The translated public record counts the duplicate as two separate reviewers approving the request. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: State that the event may be redelivered and approvals require deduplication by stable event identifier. To review the translation, perform this check: Compare event IDs, sender identity and business rules. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 4: A durable timer wakes the process
In this teaching scenario, The deadline fires while the reviewer still has not approved the certificate. The draft English sentence is overly strong: A localized interface describes the reviewer as having rejected the certificate. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: Write that the approval window expired without a decision, triggering an escalation path. To review the translation, perform this check: Check the timer fire time and any approval event history. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 5: A client starts an orchestration
In this teaching scenario, An HTTP starter returns an instance ID and management links. The draft English sentence is overly strong: The translated API response promises the final report is already ready to download. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: Explain that a start response identifies a running or pending instance whose status must be queried later. To review the translation, perform this check: Call the status endpoint and inspect output. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 6: An activity is retried after a timeout
In this teaching scenario, A provider may have processed the first operation before the client timed out. The draft English sentence is overly strong: A translated runbook says retry always guarantees one external side effect. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: Explain that repeat attempts may occur and the remote operation needs an idempotency key. To review the translation, perform this check: Inspect provider transaction IDs and activity retry history. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 7: A fan-out job has one failed branch
In this teaching scenario, Nine files were processed and the tenth activity returned an exception. The draft English sentence is overly strong: The translated status says all ten documents were verified because most tasks succeeded. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: Distinguish completed branches from the failed branch and any partial-aggregation policy. To review the translation, perform this check: Check each activity result before announcing group completion. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 8: A sub-orchestration fails
In this teaching scenario, A child orchestration throws while the parent catches the failure and selects a fallback route. The draft English sentence is overly strong: The translated alert incorrectly declares that the parent instance necessarily failed. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: Explain the child’s failure and the parent’s actual recovery decision separately. To review the translation, perform this check: Inspect parent and child instance status. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 9: The application uses custom progress
In this teaching scenario, The orchestrator sets a custom status such as awaiting-review while its runtime status remains Running. The draft English sentence is overly strong: A translator replaces runtime status with the custom label and loses the technical state. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: Show both the platform lifecycle and the application-level stage. To review the translation, perform this check: Read both fields from the status response. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 10: An administrator terminates an instance
In this teaching scenario, The orchestration is terminated after an external email was already sent. The draft English sentence is overly strong: The localized confirmation says the email was automatically recalled. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: State that orchestration termination does not retroactively undo an external send. To review the translation, perform this check: Reconcile delivery logs and any compensating procedure. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 11: An instance uses ContinueAsNew
In this teaching scenario, A recurring job continues with updated input and refreshed history. The draft English sentence is overly strong: The translated report counts each continuation as an unrelated customer order. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: Explain the logical continuity and the technical history transition distinctly. To review the translation, perform this check: Check business key, instance ID semantics and continuation input. A trustworthy multilingual guide should support the same cautious operational action in every language.
Exercise 12: A new deployment changes orchestrator code
In this teaching scenario, An in-flight instance has history created by an earlier implementation. The draft English sentence is overly strong: The translation promises every old instance will follow new branching code without compatibility checks. Identify the platform state, the external action and the specific evidence the author has not supplied.
Translate the distinction instead of the overconfident claim: Explain that deterministic replay compatibility and versioning must be assessed. To review the translation, perform this check: Test replay with representative old histories before release. A trustworthy multilingual guide should support the same cautious operational action in every language.
Frequently asked questions
Does orchestrator replay mean an activity always runs again?
No. Replay rebuilds orchestrator state using its recorded event history, including the results of completed activities. Retry or new scheduling can still cause activity execution, so inspect history and external effects. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
Why should orchestrator code be deterministic?
Replay needs the same logical decisions from the same history. Uncontrolled current time, fresh randomness and direct I/O can change decisions and make replay unreliable. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
Can external events be duplicated?
Yes. Durable Functions external events have at-least-once delivery characteristics in relevant failure conditions. Use stable event identifiers and deduplication for important decisions. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
Does a durable timer send a customer notification?
Not by itself. It schedules a wake-up for orchestration logic. A separate activity or external service must perform the notification. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
Is a successful HTTP starter response the final orchestration result?
No. It commonly provides an instance ID and management links for later status retrieval. The long-running work may still be pending or running. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
What is the difference between an activity and an orchestrator?
An orchestrator coordinates durable decisions and waits. Activities perform external work such as API calls, database updates or file generation. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
What happens after a function host restart?
Durable history can support reconstruction and continuation of orchestrations, subject to the configured platform and data store. Do not imply every downstream system has also recovered. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
Does termination undo emails or payments?
No automatic rollback of already completed external effects should be assumed. Application-level reconciliation or compensating activities may be necessary. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
Can I translate instance IDs or event names inside code?
Do not change literal routing names or identifiers in runnable examples. Explain their purpose in the target language without silently breaking matching behavior. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
Why can logs appear duplicated?
Orchestrator code can replay, potentially emitting similar diagnostic lines again. Use replay-safe logging or history correlation rather than interpreting every line as fresh business work. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
Should I describe timeout as rejection?
No. A timeout often means the application did not receive the needed event within a window; it does not prove an explicit negative human decision. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
How should a translator check a recovery claim?
Review the code and SDK version, run safe retry and restart tests, inspect durable history and verify the remote system’s record. State remaining uncertainty plainly. The same distinction should survive translation into a language with different aspect, tense or technical vocabulary; avoid unconditional verbs where the original state is only provisional.
Authoritative documentation and further reading
Use current vendor references for the chosen language SDK and hosting setup. Durable runtime behavior, storage providers and APIs can differ by version, so examples should be tested against the deployed application before they are reused operationally.
Azure Durable Functions overview
Durable orchestration concepts and replay
Durable orchestrator code constraints
External events in durable orchestrations
Related: Google Cloud Workflows localization
Conclusion: describe exactly what the history can establish
Azure Durable Functions lets an application coordinate work across restarts, waits and errors. That is powerful, but it does not erase the distinction between reconstructing orchestrator state and performing a physical external action. The professional translator preserves instance identity, activity boundaries, deterministic replay, duplicate-event handling, timers and independent business verification. Readers should know not merely what the platform can do, but what the observed evidence says happened in this particular execution.