new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Temporal · Concepts · all subjects

activities

5 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Activity naming and reference via activity type

Activities are named and referenced via the --type flag, which specifies the Activity Type name. This is a required parameter when starting or executing an Activity. An Activity ID is a separate identifier (--activity-id) used to uniquely identify a specific Activity execution.

Activity Retry Simulator tool purpose

The Activity Retry Simulator is a tool designed to visualize total Activity Execution times and experiment with different Activity timeouts and Retry Policies. It is based on a common Activity use-case of calling a third-party HTTP API and returning the results.

Activity Retry Simulator configuration options

The simulator allows configuration of Activity Retries settings to determine how long an API request takes to succeed or fail, includes an option to generate scenarios, and simulates Task Time in Queue which represents the time an Activity Task might wait in the Task Queue.

Activity Retry Simulator analysis capability

The simulator allows users to use Activity Timeouts and Retry Policy settings to observe how they impact the success or failure of an Activity Execution.

Activity task re-dispatch after failover

Temporal Multi-Cluster Replication relies on asynchronous replication of Events across Clusters. In case of failover, it is possible to have an Activity Task dispatched again to the newly active Cluster due to replication task lag. Activity Execution completions are not forwarded across Clusters, and any outstanding Activities will eventually time out based on configuration. The application should have retry logic in place so that the Activity gets retried and dispatched again to a Worker after failover to the new Cluster. This is similar to handling an Activity Task timeout caused by a Worker restarting.

Give your agent this brain