Bài 08 · Retry hay rẽ nhánh

Hai kiểu "không chạy", hai công cụ khác nhau. Lẫn lộn chúng làm flow vừa chậm vừa chập chờn.

Bài toán

Chạm nút Upgrade một cách đáng tin cậy. Hai chuyện khác hẳn nhau có thể hỏng:

1. Nút không có trên màn hình (sai trang, tải chậm).
2. Nút có đó nhưng cú chạm không ăn (UI đang ổn định dở, trục trặc input thoáng qua).

Chuyện 1 là câu hỏi trạng thái — lời đáp là phát hiện với timeout trung thực, và một nhánh rẽ. Chuyện 2 là lỗi vận hành — lời đáp là retry policy trên cú chạm.

Bạn sẽ học được

• Gắn retry policy — số lần thử, kết quả nào được thử lại, backoff.
• Vì sao retry trên Find Image để "tìm kỹ hơn" chẳng làm gì cả.
• Ba kết thúc gọi tên thứ đã hỏng.

Trước khi bắt đầu

• Hoàn thành Bài 07.

Flow

Badge đánh số node theo thứ tự đọc, khớp phần Dựng flow. Retry policy chủ đích không hiện trên canvas: nó là thuộc tính của node, nên canvas chỉ hiện nhánh bạn nối cho thất bại mà retry không chữa được.

Dựng flow

1. Flow mới. Find Image 1. Find Upgrade, template = biểu tượng mũi tên Upgrade, timeout 6000 ms, không retry policy.
2. Click 2. Tap it, nguồn tọa độ = node 1. Trong Properties, mở phần retry và đặt:

Thiết lập retry	Giá trị	Ý nghĩa
Max attempts	3	Ba lần thử tổng cộng (lần đầu + hai lần thử lại)
Retry on	failure, timeout	Hai kết quả duy nhất được thử lại
Backoff	500 ms	Chờ trước lần thử 2
Backoff multiplier	1.5	Lần thử 3 chờ 750 ms

3. Ba Stop như sơ đồ — chú ý hai thông điệp thất bại khác nhau.
4. Nối, Save, Auto Layout.

Ý tưởng làm nên bài học này

Phát hiện vốn đã tự thử lại. Find Image chụp lại và so lại mỗi chu kỳ poll suốt cả timeout — đó chính là vòng thử lại của nó. Con số 6000 ms nói: "nút này chính đáng có thể mất tới sáu giây mới tồn tại".

Và đây là cái bẫy: thêm retry policy vào Find Image chẳng giúp gì cho "không thấy". Một lần không-thấy rời qua Failure nhưng mang status success — bản thân việc tìm đã chạy đúng; thứ cần tìm không có đó. Retry chỉ kích hoạt trên status failure/timeout. Nên phản xạ "thêm retry cho tìm kỹ" là con số không tròn trĩnh; cách sửa trung thực là thêm timeout, template tốt hơn, hoặc chấp nhận nhánh rẽ.

Hành động thì ngược lại. Một Click hoặc gửi đi được, hoặc hỏng về mặt vận hành — không có vòng poll nào để kéo dài. Lỗi input thoáng qua chính xác là thứ retry-kèm-backoff sinh ra để xử: khoảng nghỉ 500 ms cho thứ vừa nuốt cú chạm kịp ổn định trước lần thử hai.

Ba kết thúc, vì hai thứ có thể hỏng. not found và tap failed after 3 attempts chỉ bạn đến hai chỗ sửa khác nhau ngay từ cái liếc — một bên là vấn đề điều hướng/template, bên kia là vấn đề input/thiết bị. Một Stop "failed" dùng chung sẽ chôn mất điều đó.

Chạy thử

• Dashboard phía trước: khớp, chạm, success · Upgrade queued (nhật ký hoạt động thêm dòng "Upgrade queued").
• Sai màn hình phía trước: sáu giây poll → failure · Upgrade button not on this screen. Chú ý nhật ký chạy cho thấy Find Image thực thi một lần — không retry nào chạy, đúng như thiết kế.

Kết thúc chạm-hỏng khó tự tạo trên giả lập khỏe mạnh — đó chính là ý nghĩa của việc nó là nhánh hiếm. Tin vào dây nối; bạn sẽ gặp nó ngoài đời.

Best practices

• Retry cho hành động, timeout cho phát hiện. Nhắc đến khi thành phản xạ.
• 2–3 lần thử, luôn kèm backoff. Thử lại tức thì thường đâm trúng đúng khoảnh khắc bận đó; mười lần thử chỉ trì hoãn sự thật.
• Đặt tên kết thúc thất bại theo thứ đã hỏng.
• Tắt captureScreenshotPerAttempt trong vận hành — chỉ bật khi chẩn đoán, nó ghi một ảnh mỗi lần thử.
• Nhớ trường hợp xấu nhất: 3 lần thử × timeout + các khoảng backoff. Retry nhân thời gian chẳng kém gì vòng lặp.

Lỗi thường gặp

Lỗi	Hậu quả	Cách sửa
Retry policy trên Find Image cho "không thấy"	Không bao giờ chạy — status là success	Tăng timeout
Attempts = 10	Đứng hình lâu trước khi chịu nhận thất bại	2–3 kèm backoff
Không backoff	Mọi lần thử đâm cùng một khoảnh khắc bận	400–800 ms, ×1.5
Một Stop thất bại dùng chung	Không biết thứ gì vỡ	Mỗi loại hỏng một kết thúc
Thử retry một fatal	Bất khả theo thiết kế — fatal nghĩa là cấu hình sai	Sửa cấu hình

Khắc phục sự cố

"Not found" dù nút hiện rõ. Test Node → xem độ tin cậy; bắt lại template sát hơn nếu thấp. Retry không phải câu trả lời ở đây — đó chính là bài học.

Lần chạy nào cũng ngốn trọn sáu giây. Bạn luôn ở nhánh Failure; template không bao giờ khớp. Sửa template, đừng cắt timeout.

Biến của node được retry nhìn lạ lạ. Output mapping áp dụng một lần, cho lần thử cuối — các lần trước không bao giờ ghi. Chủ đích thiết kế.

Tóm tắt

• Timeout của phát hiện là retry của nó; policy-retry cho "không thấy" là vô tác dụng.
• Retry policy thuộc về thao tác có thể hỏng thoáng qua — ít lần thử, backoff thật.
• Thất bại khác nhau xứng đáng kết thúc khác nhau.

Tiếp theo

Retry chữa một thao tác chập chờn. Nhưng khi cả màn hình sai — một popup chưa từng thấy, một trang không mong đợi? Bài 09 · Quy trình khôi phục dựng lối thoát có giới hạn mà mọi automation chạy dài đều cần.

Xem thêm: Retry và thất bại · Click · Find Image