Add Standalone Activities Interactive Demo page [experimentation]#4331
Add Standalone Activities Interactive Demo page [experimentation]#4331jsundai wants to merge 4 commits into
Conversation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
jsundai
changed the title
📖 Docs PR preview links
|
| ::: | ||
|
|
||
| Standalone Activities let you run a single Activity straight from your application without | ||
| writing a Workflow. Your code calls the Temporal Client, the Server durably enqueues the request |
There was a problem hiding this comment.
| writing a Workflow. Your code calls the Temporal Client, the Server durably enqueues the request | |
| writing a Workflow. Your code uses the Temporal Client to send the request to the Server, the Server durably enqueues the request |
| `ActivityHandle` that was created when the Activity was scheduled. | ||
|
|
||
| Because the Server durably persists the Activity, it survives Worker restarts and network | ||
| interruptions. If the Activity fails, the Server automatically retries it according to the Retry |
There was a problem hiding this comment.
"it survives Worker restarts and network interruptions"
I feel like we use similar language for Workflows. Is it worth adding something like (I'm not saying this is the right phrasing)
However, unlike a Workflow, an Activity is by default re-executed from the beginning on each attempt, so you should typically do one operation with side effects in an Activity. If you need to do two different operations (both with side effects), you should typically use a Workflow with two Activities.
| ? config.failCount > config.maxRetries | ||
| ? `All ${config.maxRetries + 1} attempt(s) will fail because failCount exceeds maxRetries.` | ||
| : `Activity will fail ${config.failCount} time(s), then succeed on attempt ${config.failCount + 1}.` | ||
| : null; |
There was a problem hiding this comment.
It would be nice to style this as an error because it's saying that the user input doesn't make sense.
| update(['completed', 'completed', 'pending', 'pending', 'pending'], null); | ||
|
|
||
| // ── Retry loop ─────────────────────────────────────────────────────── | ||
| while (true) { |
There was a problem hiding this comment.
Does setting StartToClose timeout actually do anything? Here it succeeds even though StartToClose was zero.
Related, I thint here should be a way to set the duration that each attempt takes, so that user scan understand that a StartToClose timeout failure occurs when the duration of an individual attempt exceeds the specified timeout.
And related, shall we add ScheduleToStart timeout also, so that users can understand that it occurs when something spends too long in the queue (typically due to insufficient worker resources).
|
|
||
| ## How it works | ||
|
|
||
| When you call `client.ExecuteActivity()` (or the equivalent in your SDK), the following happens: |
There was a problem hiding this comment.
The code written there looks like Go SDK code. Unfortunately, the Go SDK is different from all other SDKs: "ExecuteFoo" in Go means what "StartFoo" means in other SDKs. So, ExecuteActivity() in Go does not poll. A simple fix would be to use Python code: client.execute_activity().
To see what I mean, see the Go code from the docs here:
handle, err := c.ExecuteActivity(context.Background(), activityOptions, helloworld.Activity, "Temporal") // Just sends it to the server
...
err = handle.Get(context.Background(), &result) // this does the polling for result in Go!| | Orchestrated by | A Workflow Definition | Your application code (via the Temporal Client) | | ||
| | Started with | SDK-specific (for example, `workflow.ExecuteActivity()` in Go) | SDK-specific (for example, `client.ExecuteActivity()` in Go, `client.StartActivityAsync()` in .NET) | | ||
| | Retry policy | Set in `ActivityOptions` inside your Workflow | Set in `StartActivityOptions` when calling the client | | ||
| | Visibility | Shown in the Workflow's Event History | Shown in the Activity list and count views | |
There was a problem hiding this comment.
If this is referring to what they see in the UI then
| | Visibility | Shown in the Workflow's Event History | Shown in the Activity list and count views | | |
| | Visibility | Shown in the Workflow's Event History | Shown in the Standalone Activity list and count views | |
| activityType = 'ComposeGreeting'; | ||
| inputFlag = `--input '{"Greeting": "${GREETING}", "Name": "${name}"}'`; | ||
| } | ||
|
|
There was a problem hiding this comment.
It's bothering me a bit that in one place the input is a class instance containing two fields, and in the CLI the user sees the JSON representation of that, but in the input form field in the simulation then just enter the "name" bit, and in the log it suggests that the activity only takes one argument. Maybe the whole thing would be simpler if it just has a single string argument and we don't try to teach them about using classes/structs as input in this demo?
2 participants
What does this PR do?
preview https://temporal-documentation-git-feat-standalone-activities-in-03cd2c.preview.thundergun.io/develop/standalone-activities-interactive-demo
Notes to reviewers
┆Attachments: EDU-6095 Add Standalone Activities Interactive Demo page [experimentation]