Tôi vừa có chuyến đi về Ninh Thuận vào những ngày cuối tháng 10 vừa rồi. Không tính toán gì trước, vợ tôi có lướt Tiktok rồi thấy một homestay view biển ở làng chài, muốn đi thế là chốt. Đây cũng là lần đầu con gái của chúng tôi đi máy bay. Trộm vía bé (7 tháng) ngoan, trừ lúc bay về có khóc một chút, chắc do đau tai, tôi cũng bị đau một bên tai trái. ...
Temporal - Activity Options
To continue the series about Temporal, in this blog post, I will talk about the activity options in detail. Understanding the meaning of the important fields will help to control the behavior of the activity execution, retries and resilient to service/pod restarts. The Temporal has really insightful and detail document and code comments about these fields, but here’s the recap: StartToCloseTimeout: The maximum amount of time an activity is allowed to run in a single attempt. If the activity exceeds this duration, it times out and is considered failed for that attempt. Temporal will then either retry it based on the RetryPolicy or mark the activity as failed if no retries remain. ScheduleToCloseTimeout: The maximum amount of time from when an activity is scheduled until it completes, including all retries. You must specify either this value or StartToCloseTimeout when starting an activity. RetryPolicy: Controls the retry behavior, including exponential backoff settings. There is a NonRetryableErrorTypes field that you should pay attention to. HeartbeatTimeout: The required interval for an activity to call RecordHeartbeat to communicate liveness to the Temporal Service. If the activity fails to send a heartbeat within this interval, it is treated as failed and the Temporal Service will retry it according to the RetryPolicy. flowchart TD A[Activity Scheduled] A --> B{ScheduleToCloseTimeout expired?} B -->|Yes| F[Fail: ScheduleToCloseTimeout → No more retries] B -->|No| C[Start Attempt] C --> D{HeartbeatTimeout configured?} D -->|No| E[Run Activity] D -->|Yes| H[Run Activity + Expect Heartbeats] H --> I{Heartbeat received before HeartbeatTimeout?} I -->|No| J[Attempt failed: HeartbeatTimeout] I -->|Yes| E[Continue running attempt] E --> K{Finish before StartToCloseTimeout?} K -->|Yes| L[Attempt Succeeded → Activity Succeeds] K -->|No| M[Attempt failed: StartToCloseTimeout] %% After an attempt fails (Heartbeat or StartToClose) J --> N{ScheduleToCloseTimeout expired now?} M --> N N -->|Yes| F N -->|No| R{RetryPolicy allows retry?} R -->|Yes| A R -->|No| X[Workflow receives failure result] Timeout Set a meaningful StartToCloseTimeout based on how long the activity should normally take to finish. Avoid setting it too large without a HeartbeatTimeout, because the workflow can become stuck for a long time if the worker restarts and the activity does not report progress. Set a ScheduleToCloseTimeout when using heartbeat-enabled activities to ensure retries stay within a reasonable overall time window. In Golang, the pattern when using heartbeat looks like ...
Đầu Tư Quỹ ETF tại Việt Nam
<!DOCTYPE html> Cẩm Nang Đầu Tư Quỹ ETF Toàn Diện tại Việt Nam Cẩm Nang Đầu Tư Quỹ ETF Toàn Diện Phân tích, so sánh và giả lập danh mục tại thị trường Việt Nam ...
Temporal - Workflow Determinism
One of my recent favourite technologies is Temporal. It’s durable execution platform—a modern toolkit for building resilient, long-running workflows in a code-centric, scalable way. Basically, it helps engineers build a reliable workflow by providing ways to retry, resume, and replay the execution at the desired point in time. Below is the highlevel overview of Temporal’s components. This post will focus on the Workflow code that is engineer’s responsibility to control. ...
Hello world
This is my very first post here. It’s actually the second time I’ve tried starting a blog. I’m mainly interested in software engineering, music, and movies—and I hope to keep this one going for a long time as a space to share my thoughts.