Mô hình thực thi

Mọi thứ một flow làm lúc chạy đều đến từ một vòng lặp nhỏ: chọn một node, chạy nó, nhìn kết quả nó trả về, đi theo một edge đến node kế. Khi bạn dự đoán được vòng lặp đó, bạn dự đoán được flow của mình.

Trang này mô tả vòng lặp đúng như runtime cài đặt nó. Nếu một flow hành xử khiến bạn ngạc nhiên, câu trả lời gần như luôn nằm ở trang này.

Mục đích

Hiểu mô hình thực thi cho phép bạn:

• Dự đoán node nào chạy kế tiếp mà không cần chạy flow.
• Phân biệt "flow của tôi thất bại" với "flow của tôi rẽ nhánh kia" — trong log trông giống nhau mà nghĩa ngược nhau.
• Biết vì sao một lần chạy dừng, và rào chắn nào trong ba rào chắn đã dừng nó.
• Nối các đường xử lý lỗi một cách chủ đích thay vì thử-sai.

Khi nào bạn cần trang này

Đọc trang này trước khi xây bất kỳ thứ gì có rẽ nhánh, vòng lặp, hay xử lý lỗi. Bạn cần nó khi:

• Một node "thành công" nhưng flow đi đến chỗ không ngờ.
• Một lần chạy kết thúc ngay lập tức không lỗi rõ ràng.
• Bạn đang phân vân xử lý một vấn đề bằng retry, bằng edge failure, hay bằng một If.

Bạn không cần trang này để xây một đường thẳng toàn Click và Wait.

Mỗi lần một node

Một flow đang chạy là một session. Mỗi session thực thi đúng một node tại một thời điểm và giữ một con trỏ "node hiện tại".

Điều này quan trọng hơn vẻ ngoài của nó:

• Không có node chạy nền. Không gì khác trong flow chạy trong khi một node đang chạy.
• Node chậm chặn cả session. Một Find Image timeout 30 giây dừng session đó tới 30 giây.
• Tính song song đến từ nhiều session hơn (nhiều instance hơn), không phải từ việc chẻ một flow.

Song song thật đến từ đâu

Muốn làm hai việc cùng lúc, chạy flow trên hai instance, hoặc dùng Flow Queue để chạy nhiều flow trên đội instance của bạn. Trong một session, thực thi tuần tự tuyệt đối.

Vòng lặp

Đây là vòng lặp chính của runtime, theo đúng thứ tự nó chạy:

Hai hệ quả đáng thuộc lòng:

1. fatal và cancelled không bao giờ đi theo edge. Nối port Fatal không tạo ra đường cứu hộ trong lần chạy bình thường — runtime kết thúc ngay khi thấy status đó. Dùng failure cho mọi thứ bạn định phục hồi.
2. Route không có edge sẽ kết thúc lần chạy. Nếu node trả failure mà không gì nối vào port Failure, lần chạy kết thúc failure với TRANSITION_NOT_FOUND. Nó không âm thầm đi tiếp.

Status với route — sự phân biệt quan trọng nhất

Mỗi node trả về hai thứ tách biệt:

	Nó mô tả gì	Ai đọc nó
status	Sức khỏe thực thi — bản thân node có chạy được không?	Runtime, cho rào chắn và retry
route	Flow rời qua port nào	Phân giải edge, để chọn node kế

Chúng không phải một, và với các node phát hiện chúng chủ ý khác nhau.

Năm status

Status	Ý nghĩa	Retry được	Đi theo edge
success	Node hoàn tất bình thường	—	Có
failure	Thất bại phục hồi được	Có	Có
timeout	Điều kiện chờ không đạt kịp lúc	Có	Có
cancelled	Lần chạy bị dừng giữa node	Không	Không — kết thúc
fatal	Lỗi hệ thống hoặc cấu hình không phục hồi được	Không	Không — kết thúc

Vì sao "không thấy" không phải thất bại

Đây là nguồn nhầm lẫn phổ biến nhất, nên đáng nói thẳng.

Khi Find Image tìm template và timeout hết mà không khớp:

• status là success — phép phát hiện chạy đúng, chỉ là không tìm thấy ảnh;
• route là failure — nên flow rời qua port Failure.

Hiệu ứng thực tế: một lần "không thấy" không bao giờ tính vào rào chắn lỗi-liên-tiếp và không bao giờ kích hoạt node retry. Một flow poll một sự kiện hiếm cả nghìn lần sẽ không bị giết vì điều đó. Đó là chủ đích — "nút chưa hiện" là kết cục bình thường, không phải lỗi.

Khuôn mẫu tương tự áp dụng cho Check Region (passed / không đạt) và Read Text.

Đọc nó như câu hỏi, không như phán quyết

Với node phát hiện, đọc các port như câu trả lời cho một câu hỏi — "nó có đó không?" — chứ không phải "node này có chạy được không?". Node chạy được trong cả hai trường hợp.

Phân giải edge

Khi node trả route R, runtime tra các edge rời (nodeNày, R):

1. Ứng viên được lập chỉ mục sẵn lúc biên dịch theo (fromNodeId, fromPort).
2. Sắp theo priority tăng dần, rồi theo id edge tăng dần.
3. Ứng viên đầu tiên không có điều kiện thắng.
4. Ứng viên có điều kiện được định giá; true chọn nó, false đi tiếp.
5. Nếu điều kiện lỗi hoặc trả về không-boolean, ứng viên đó bị bỏ qua và tiếp tục ứng viên kế.
6. Không gì được chọn → "không có edge" — và lần chạy kết thúc failure.

Phân giải edge là thuần túy: nó không bao giờ chụp khung hình, gửi input, đổi biến, hay ghi file. Nó chỉ chọn.

Pipeline thực thi node

Bên trong "chạy node", các pha luôn theo thứ tự này:

Những điểm hay gây bất ngờ:

• Nếu một {{biến}} trong tham số không phân giải được, node trả fatal với PARAM_EXPRESSION_INVALID trước bất kỳ retry nào. Biểu thức hỏng là bug cấu hình, retry nó chỉ hỏng y hệt.
• Output mapping chạy đúng một lần, trên lần thử cuối. Node retry ba lần không ghi biến ba lần.

Rào chắn

Ba giới hạn bảo vệ bạn khỏi flow chạy mãi không dừng. Cả ba là thiết lập của flow, do chính runtime kiểm tra.

Rào chắn	Kiểm lúc	Hiệu ứng khi vượt
maxNodeExecutions	Trước mỗi node	kết thúc fatal, MAX_NODE_EXECUTIONS_EXCEEDED
maxRuntimeDurationMs	Trước mỗi node	kết thúc fatal, MAX_RUNTIME_DURATION_EXCEEDED
maxConsecutiveFailures	Sau mỗi node	kết thúc fatal, MAX_CONSECUTIVE_FAILURES_EXCEEDED

Bộ đếm lỗi liên tiếp hành xử như sau:

• failure và timeout tăng nó.
• success đưa nó về 0.
• fatal và cancelled kết thúc lần chạy trước khi bộ đếm được hỏi tới.

Vì "không thấy" của phát hiện mang status success, nó đưa bộ đếm về 0 thay vì tăng.

Flow chạy dài cần dư địa

maxNodeExecutions đếm mọi node, kể cả Start và Stop. Một flow có vòng lặp 200 lượt trên 12 node thực thi ~2400 node. Các flow kiểu Farm trong bộ tài liệu này đặt maxNodeExecutions là 5000 chính vì lý do đó. Nếu một flow dài chết với MAX_NODE_EXECUTIONS_EXCEEDED, hãy nâng giá trị này thay vì cắt ngắn vòng lặp.

Thời gian backoff của retry không tính vào timeout của từng lần thử, nhưng có tính vào maxRuntimeDurationMs.

Một lần chạy kết thúc thế nào

Lần chạy kết thúc theo đúng một trong các cách:

Nguyên nhân	Trạng thái cuối
Đến node Stop	theo tuyên bố của Stop (success / failure / cancelled)
Đến node Return	theo tuyên bố của Return
Một node trả fatal	fatal
Một node trả cancelled, hoặc người dùng dừng	cancelled
Route không có edge khớp	failure (TRANSITION_NOT_FOUND)
Vượt rào chắn	fatal

Không tồn tại flow "chạy hết đường" — mọi nhánh hoặc đến node kết thúc hoặc kết thúc bằng TRANSITION_NOT_FOUND.

Ví dụ lần theo từng bước

Xét một bước đăng nhập nhỏ:

Lần theo khi nút hiện muộn:

Bước	Node	status	route	Kế tiếp
1	Start	success	success	Find Image
2	Find Image	success	failure	Wait 2s
3	Wait 2s	success	success	Find Image (lần 2)
4	Find Image (lần 2)	success	success	Click
5	Click	success	success	Stop
6	Stop	—	—	kết thúc success

Chú ý bước 2 mang status success dù nó rẽ sang Failure. Bộ đếm lỗi liên tiếp không nhúc nhích, không retry nào dính dáng. Flow đơn giản đi nhánh kia của nó.

Best practices

• Nối port Failure của mọi node phát hiện. Port Failure bỏ trống biến "không thấy" thành một lần chạy bị kết thúc.
• Dùng failure cho phục hồi, không phải fatal. fatal kết thúc ngay và không bắt được.
• Ưu tiên rẽ nhánh hơn retry cho "nó có chưa?" Retry dành cho thao tác thực sự hỏng; nhánh rẽ dành cho màn hình đang ở trạng thái khác.
• Cho flow dài maxNodeExecutions hào phóng. Nó là lưới an toàn, không phải ngân sách.
• Để success reset bộ đếm lỗi. Xen kẽ bước thành công giữa các bước rủi ro tự nhiên giữ maxConsecutiveFailures không sập bẫy.

Ghi chú hiệu năng

• Vì session chạy mỗi lần một node, tổng thời gian flow là tổng thời gian các node. Cách nhanh nhất tăng tốc một flow là rút ngắn timeout ở các node thường thành công tức thì, không phải tổ chức lại đồ thị.
• timeoutMs của node dạng poll bao trùm cả vòng poll — chụp hình, cắt, so khớp, phát sự kiện. Đặt poll 1 giây trong timeout 2 giây cho bạn chừng hai lần thử, không phải hai giây so khớp.
• Phân giải edge thuần túy và lập chỉ mục sẵn, nên bản thân việc rẽ nhánh gần như miễn phí. Đừng ép phẳng một đồ thị dễ đọc vì tốc độ.

Ghi chú bộ nhớ

• Mỗi session giữ ngữ cảnh thực thi riêng: biến, nodeResults, và lastResult. Chạy cùng flow trên 10 instance tạo 10 ngữ cảnh độc lập.
• nodeResults lớn dần theo mỗi node thực thi, vì kết quả từng node được ghi lại cho tham chiếu sau (đây là thứ cho phép If kiểm kết cục một node phía trên). Flow với maxNodeExecutions rất cao và hàng nghìn lượt lặp tích lũy dữ liệu kết quả suốt đời lần chạy.
• Ưu tiên tách automation chạy rất dài thành một Sub Flow được gọi lặp lại, hoặc thành các lần chạy theo lịch, thay vì một session thực thi hàng giờ.

Lỗi thường gặp

Lỗi	Hậu quả	Cách sửa
Bỏ trống port Failure	Lần chạy kết thúc TRANSITION_NOT_FOUND	Nối nó, dù chỉ về một Stop
Kỳ vọng Fatal làm lưới hứng	Không bao giờ được đi; lần chạy kết thúc	Xử lý vấn đề phục hồi được trên failure
Thêm retry vào Find Image để "tìm kỹ"	Retry không nổ — không-thấy mang status success	Nâng timeoutMs, hoặc rẽ trên Failure
Coi "không thấy" là lỗi khi đọc log	Đọc nhầm flow khỏe thành hỏng	Nhìn route, không chỉ status
Flow rất dài với maxNodeExecutions mặc định	Chết giữa chừng vì MAX_NODE_EXECUTIONS_EXCEEDED	Nâng giới hạn trong flow settings

Khắc phục sự cố

Lần chạy kết thúc ngay và log ghi TRANSITION_NOT_FOUND. Một node trả route không có edge. Tìm node cuối trong log và xem nó dùng port nào.

Lần chạy kết thúc MAX_CONSECUTIVE_FAILURES_EXCEEDED mà node nào trông cũng ổn. Có gì đó trả failure hoặc timeout lặp đi lặp lại không chen thành công nào. Tìm node hành động (không phải node phát hiện) hỏng liên tục.

Node có retry policy không bao giờ retry. Hoặc nó trả fatal (không bao giờ retry), hoặc nó trả status success với route failure (phát hiện không-thấy) — không phải kết quả retry được.

Flow rẽ nhánh khác kỳ vọng. Xem route của node, không phải status. Với node phát hiện, hai thứ này khác nhau theo thiết kế.

FAQ

fatal có rollback gì không? Không. fatal kết thúc lần chạy. Input đã gửi tới thiết bị thì đã xảy ra rồi.

Hai node có thể chạy cùng lúc trong một flow không? Không. Một session thực thi mỗi lần một node. Dùng nhiều instance cho đồng thời.

Node retry 3 lần thì output mapping chạy 3 lần? Không — đúng một lần, áp cho kết quả của lần thử cuối.

Edge từ port cancelled có bao giờ được đi? Không. Port cancelled có thể tồn tại trên canvas cho tương thích tương lai, nhưng runtime kết thúc trên cancelled mà không đi edge.

Trang liên quan

• Giải phẫu Flow — flow được cấu thành từ gì
• Retry và thất bại — retry policy chi tiết
• Biến và bộ nhớ — ngữ cảnh mà vòng lặp này mang theo
• Tra cứu Node — port và status theo từng node