From cbff022fe1aadeaa6cae63421ad69c8730e45b5e Mon Sep 17 00:00:00 2001 From: Dan Farrelly Date: Fri, 1 Nov 2024 17:14:11 -0400 Subject: [PATCH] Move assets to new CDN --- ...urable-functions-a-visual-javascript-primer.mdx | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/pages/blog/_posts/durable-functions-a-visual-javascript-primer.mdx b/pages/blog/_posts/durable-functions-a-visual-javascript-primer.mdx index 4e7d15e40..0c18311c5 100644 --- a/pages/blog/_posts/durable-functions-a-visual-javascript-primer.mdx +++ b/pages/blog/_posts/durable-functions-a-visual-javascript-primer.mdx @@ -169,27 +169,27 @@ Here's a run of our `orderProcessingWorkflow()`: 1. An `"order.placed"` event is sent to Inngest. In this case, this is done within our application's custom `api/order` endpoint, which for example can be triggered when an order is placed. This sends an HTTP request to the Inngest Platform. 2. Inngest's Platform receives this request, which in turn triggers the engine to identify the matching functions. Within the engine, it creates a new job for the execution of the matching function (`orderProcessingWorkflow` in this case), and queues this job. - + 3. The engine picks up this job when it's first in the queue, and sends a request to your app's `/api/inngest` endpoint. This request includes all the information that the SDK needs to run `orderProcessingWorkflow` and the state indicating that step #1 hasn't run yet. 4. The SDK receives this request. It executes `orderProcessingWorkflow`, and runs step #1. - + 5. After running step #1, the SDK sends a request to the engine with the data from step #1, and a request to run step #2. 6. The Engine receives the response with the incremental state update, stores it, and picks up the run again. - + 7. The Engine sends a request to the SDK which indicates that step #2 should be run next. 8. The SDK receives this request. It re-runs the entire workflow, but skips step #1 since this has already been memoized. It then discovers step #2, and executes this. - + 9. The SDK returns a response with step #2's state and return value, and information that lets the SDK know run step #3 next. - + This process continues, with the Engine and SDK communicating back and forth, executing steps, and managing state until the entire workflow is completed. When the workflow has been completed, the SDK responds with a `200 OK` response, and the job is removed from the jobs queue. @@ -200,11 +200,11 @@ Throughout the workflow, any step that encounters an issue executes predefined e 1. The SDK tries to execute `check-inventory` , but an exception is thrown (in real life, this could be caused by e.g. a server timeout). The SDK catches this, returns an `error` object in the response, and includes a default retry configuration if none is provided. 2. The Engine receives the error response, stores the run state including error details, and schedules a retry based on the retry configuration (default is 4 retries). - + 3. After the first delay of 15 seconds, the Engine initiates the first retry by resending another request. The SDK skips `process-payment` as this is already memoized, and attempts to run `check-inventory` again. In this case, the second attempt succeeds. - + If it were to fail again, the process repeats from step 3. This retry cycle continues until either the step succeeds or the maximum retries (4 by default) are exhausted. If all retries are exhausted, the Engine marks the step and workflow as failed, and stores the final error state for debugging and potential manual intervention.