Retry và xử lý thất bại

Automation trên màn hình sống thất bại liên tục và bình thường: hiệu ứng còn đang chạy, một cuộc gọi mạng chậm, một hộp thoại hiện muộn. Flow coi mọi trục trặc là sập đổ thì vô dụng. Flow retry mọi thứ mãi mãi còn tệ hơn.

Trang này giải thích ba công cụ xử lý thất bại, và — quan trọng hơn — khi nào mỗi công cụ là lựa chọn sai.

Mục đích

Đọc xong trang này, bạn nhìn một bước đang hỏng và nói được nó cần cái nào:

1. Timeout dài hơn — thứ đó sẽ đến, chỉ là muộn hơn.
2. Edge failure — màn hình đang ở trạng thái khác, đi đường khác.
3. Retry policy — thao tác thực sự hỏng và lặp lại có thể thành.

Chọn sai là lý do flow trở nên chậm, chập chờn, hoặc cả hai.

Retry là thuộc tính của node, không phải một node

Không có node "Retry". Retry là policy gắn vào node, cấu hình trong Properties panel.

{
  "maxAttempts": 3,
  "retryOn": ["failure", "timeout"],
  "backoffMs": 500,
  "backoffMultiplier": 1.5,
  "captureScreenshotPerAttempt": true
}

Từng thiết lập

Thiết lập	Kiểu	Khoảng	Mặc định	Ý nghĩa
maxAttempts	integer	1–20	—	Tổng số lần thử kể cả lần đầu
retryOn	list	failure, timeout	—	Kết quả nào retry được
backoffMs	integer	0–60000	—	Chờ trước lần thử kế
backoffMultiplier	number	1–10	—	Nhân khoảng chờ mỗi lần
captureScreenshotPerAttempt	boolean	—	false	Lưu ảnh chụp mỗi lần thử

maxAttempts: 3 nghĩa là ba lần thử tổng cộng, không phải một cộng ba.

Với backoffMs: 500 và backoffMultiplier: 1.5, các khoảng chờ là 500 ms, rồi 750 ms, rồi 1125 ms.

Thứ không bao giờ được retry

retryOn chỉ chứa được duy nhất failure và timeout. Schema từ chối mọi thứ khác, có lý do:

• fatal không bao giờ retry. Nó nghĩa là lỗi cấu hình hoặc hệ thống — biểu thức hỏng, vùng không hợp lệ, thiết bị mất kết nối. Lặp lại sinh đúng lỗi đó.
• success không bao giờ retry, kể cả phát hiện báo "không thấy" (mang status success).
• cancelled không bao giờ retry. Người dùng đã dừng lần chạy.

Lỗi retry phổ biến nhất

Gắn retry policy vào Find Image để "tìm kỹ hơn" không làm gì cả.

Find Image không thấy template trả status success với route failure. Retry chỉ nổ trên status failure hoặc timeout. Policy không bao giờ kích hoạt.

Muốn tìm kỹ hơn, nâng timeoutMs — node vốn đã chụp lại và so lại mỗi chu kỳ poll. Đó chính là vòng retry của phát hiện.

Vòng đời một lần thử

Hai quy tắc rút ra từ sơ đồ:

1. Lỗi tham số xảy ra trước retry. Một {{biến}} hỏng là fatal và không bao giờ retry.
2. Output mapping chạy đúng một lần, trên kết quả lần thử cuối. Node retry ba lần ghi biến một lần.

Timeout và backoff

• timeoutMs trên node là timeout mỗi lần thử, không phải cả node. Node timeout 5 giây, 3 lần thử có thể tốn 15 giây thử cộng backoff.
• Backoff không nằm trong timeout một lần thử.
• Backoff có tính vào maxRuntimeDurationMs của flow.

Ba công cụ, và khi nào đúng công cụ

1. Nâng timeout

Dùng khi thứ bạn chờ sẽ xuất hiện, chỉ là không biết chính xác lúc nào.

Node phát hiện poll: chụp khung hình, so khớp, ngủ một chu kỳ, lặp cho đến timeout. Timeout dài hơn nghĩa là nhiều lần thử hơn.

Nút Claim hiện sau hiệu ứng 2 giây. → Find Image, timeoutMs: 4000, pollIntervalMs: 250.

2. Nối edge failure

Dùng khi "không có đó" nghĩa là màn hình đang ở trạng thái hợp lệ khác và bạn muốn làm việc khác.

Có ngày có popup thưởng, có ngày không. → Find Image popup, Success → đóng, Failure → đi tiếp.

Đây là rẽ nhánh, không phải xử lý lỗi. Nó là công cụ phổ biến nhất và bị bỏ quên nhất trong ba.

3. Gắn retry policy

Dùng khi thao tác thực sự hỏng theo cách lặp lại có thể chữa: input bị từ chối, trục trặc chụp hình, lỗi thiết bị thoáng qua.

Cú chạm thi thoảng bị nuốt khi UI còn đang ổn định. → Click, maxAttempts: 3, retryOn: [failure, timeout], backoffMs: 400.

Bảng quyết định

Tình huống	Công cụ	Vì sao
Nút hiện sau hiệu ứng	Timeout dài hơn	Nó đang đến
Popup có thể có hoặc không	Edge failure	Hai trạng thái hợp lệ
Màn hình thi thoảng tải chậm	Timeout dài hơn	Cùng trạng thái, muộn hơn
Cú chạm thi thoảng không ăn	Retry policy	Thao tác hỏng
Biểu thức tham chiếu biến thiếu	Không cái nào	fatal — sửa cấu hình
OCR thi thoảng đọc sai	Vòng xác minh	Xem dưới

Khuôn mẫu xác minh

Với bất kỳ thứ gì quan trọng, đừng cho rằng hành động đã thành — hãy kiểm.

Mạnh hơn retry vì nó xác nhận kết quả, không phải lời gọi. Automation tham chiếu được nghiên cứu cho bộ tài liệu này dùng đúng hình dạng đó: hành động, ổn định, xác minh, và rẽ về một nhánh bỏ-qua sạch khi xác minh trượt.

Chú ý Wait giữa hành động và xác minh. Thiếu nó, phép xác minh đọc khung hình trước-hành-động. Xem frameSync trong Giải phẫu Flow.

Rào chắn tương tác với thất bại

Runtime theo dõi lỗi liên tiếp trên cả lần chạy:

• failure và timeout tăng bộ đếm.
• success đưa về 0.
• Vượt maxConsecutiveFailures kết thúc lần chạy fatal.

Vì "không thấy" của phát hiện mang status success, vòng poll không thấy gì lâu không sập rào chắn này. Chỉ lỗi vận hành thật mới sập.

Thiết kế đường thất bại sạch

Cho mỗi flow một kết thúc tường minh, chủ đích cho ca xấu. Hai node kết thúc thường là đủ:

Đặt message trên Stop thất bại. Chuỗi đó là thứ bạn đọc trong log lần chạy lúc 2 giờ sáng, và "Max Slot Troop" hữu ích hơn một node id vô hạn lần.

Khi flow là Sub Flow, hai Stop đó thành giá trị trả về — flow cha rẽ trên port Success và Failure của con.

Best practices

• Đặt message trên mọi Stop thất bại. Nó là log của bạn.
• Ưu tiên xác minh hơn retry cho mọi thứ có side effect.
• Giữ maxAttempts nhỏ — 2 hoặc 3. Ba lần không chữa được thì mười lần cũng không.
• Dùng backoff cho mọi thứ dính thiết bị. Retry tức thì thường đâm đúng trạng thái bận cũ.
• Không bao giờ retry fatal. Bạn không thể, và muốn thế nghĩa là cấu hình sai.
• Nối mọi port Failure, dù chỉ về một Stop. Route bỏ trống kết thúc lần chạy với TRANSITION_NOT_FOUND.
• Bật captureScreenshotPerAttempt khi gỡ lỗi, rồi tắt — nó ghi một ảnh mỗi lần thử.

Ghi chú hiệu năng

• Retry nhân thời gian xấu nhất của node với maxAttempts cộng chuỗi backoff. Timeout 5 giây, 3 lần thử, backoff 500 ms ×1.5 là tới ~16 giây cho một node.
• Ưu tiên một timeout dài hơn thay vì nhiều lần thử retry với phát hiện: poll trong một lần thử không tốn backoff và không lặp chi phí khởi tạo.
• captureScreenshotPerAttempt ghi ảnh mỗi lần thử — I/O thật. Tắt trong flow vận hành.

Ghi chú bộ nhớ

• Mọi lần thử được log, và với captureScreenshotPerAttempt mỗi lần thử lưu một artifact. Chạy dài retry mạnh tay sinh thư mục lần chạy lớn.
• Chỉ kết quả lần thử cuối ghi vào nodeResults, nên retry không nhân footprint bộ nhớ của ngữ cảnh.

Lỗi thường gặp

Lỗi	Thực tế xảy ra	Cách sửa
Retry trên Find Image để "tìm kỹ"	Policy không nổ	Nâng timeoutMs
maxAttempts: 1 mong một lần thử lại	Đó là không retry	Dùng 2 cho một lần thử lại
Retry một fatal	Bất khả	Sửa cấu hình
Không chờ giữa hành động và xác minh	Xác minh khung hình cũ	Chèn Wait
Port Failure bỏ trống	Lần chạy kết thúc TRANSITION_NOT_FOUND	Nối về Stop tối thiểu
Stop thất bại không message	Log không đọc nổi	Viết lý do
maxAttempts khổng lồ trên node chậm	Lần chạy vỡ trần thời gian	Ít lần thử, rẽ nhánh thật

Khắc phục sự cố

Retry của tôi không bao giờ chạy. Node đang trả status success (phát hiện không-thấy) hoặc fatal. Chỉ status failure và timeout retry được.

Lần chạy chết MAX_CONSECUTIVE_FAILURES_EXCEEDED. Có gì hỏng lặp lại không chen thành công nào. Không-thấy của phát hiện không gây ra — tìm ở node hành động.

Node tốn lâu hơn hẳn timeout của nó. Timeout tính mỗi lần thử. Nhân với maxAttempts cộng backoff.

Biến node retry ghi trông sai. Chúng đến từ lần thử cuối duy nhất. Chủ đích thiết kế.

Flow hỏng ngay với PARAM_EXPRESSION_INVALID. Một {{biến}} trong tham số không phân giải được — thường chưa khai hoặc sai chính tả. Là fatal và xảy ra trước mọi retry.

FAQ

Retry được cả nhóm node không? Không trực tiếp. Đưa vào Sub Flow rồi rẽ trên Failure của nó, hoặc dựng vòng lặp tường minh với bộ đếm.

Backoff có tính vào timeout của node? Không — nhưng có tính vào maxRuntimeDurationMs của flow.

maxAttempts: 3 là ba lần thử lại hay ba lần thử? Ba lần thử tổng: lần đầu cộng hai lần thử lại.

Nên gắn retry lên mọi thứ không? Không. Phần lớn chập chờn giải tốt hơn bằng timeout dài hơn hoặc một nhánh rẽ thật.

Trang liên quan

• Mô hình thực thi — status, route và rào chắn
• Giải phẫu Flow — mặc định flow và frame sync
• Biến và bộ nhớ — node retry ghi gì
• Tra cứu Node — chế độ hỏng theo từng node