n8n: xử lý lỗi và tránh chạy trùng trong workflow

Workflow chạy được một lần chưa đủ

Một workflow lấy dữ liệu, xử lý rồi ghi kết quả thường trông đơn giản khi mọi bước đều thành công. Khó khăn xuất hiện khi kết nối bị ngắt sau khi đầu ra đã được tạo, hoặc cùng một sự kiện được gửi lại. Nếu chỉ bấm chạy lại toàn bộ, bạn có thể tạo hai bản ghi cho một công việc.

Bài này hướng dẫn thiết kế và kiểm tra một luồng mẫu. Ví dụ không gửi email thật hay xuất bản nội dung. Hãy làm trên bản sao workflow và dữ liệu thử trước khi nối vào hệ thống đang vận hành.

Tách ba loại tình huống

• Dữ liệu không hợp lệ: thiếu mã hồ sơ, sai kiểu dữ liệu hoặc nội dung rỗng. Cần sửa đầu vào, không phải retry liên tục.

• Lỗi tạm thời: kết nối gián đoạn hoặc dịch vụ giới hạn tần suất. Có thể cân nhắc chạy lại với số lần và khoảng chờ hữu hạn.

• Kết quả chưa rõ: yêu cầu bị timeout nhưng hệ thống đích có thể đã thực hiện. Cần đối chiếu trạng thái trước khi gửi lại.

Đây là khung phân loại để thiết kế, không phải lời khẳng định rằng mọi dịch vụ đều trả mã lỗi giống nhau. Đọc tài liệu API đích để biết thao tác nào được phép retry.

Bước 1: kiểm tra trước khi tạo đầu ra

Luồng mẫu gồm: nhận dữ liệu → kiểm tra trường bắt buộc → tra mã công việc → tạo đầu ra thử → ghi trạng thái. Dùng một mã sự kiện ổn định từ nguồn nếu có. Nếu tự tạo mã mới mỗi lần nhận lại yêu cầu, mã đó không giúp nhận diện hai lần gửi của cùng một việc.

Tạo ba hồ sơ thử: một hợp lệ, một thiếu mã và một lặp lại mã của hồ sơ đầu. Sau khi chạy, bạn cần chỉ ra hồ sơ nào đã đi vào nhánh nào. Chỉ nhìn một trạng thái xanh cuối workflow chưa chứng minh từng đầu vào đã được xử lý đúng.

Bước 2: cấu hình error workflow

n8n hỗ trợ một workflow riêng bắt đầu bằng Error Trigger. Chọn workflow này trong phần Error workflow của cài đặt workflow cần theo dõi. Nội dung cảnh báo nên đủ để tìm lần chạy và node lỗi, tránh chép toàn bộ dữ liệu nhạy cảm vào thông báo.

Lưu ý cách thử: error workflow không chạy giống một lần thực thi thủ công trong editor; cần kiểm tra điều kiện kích hoạt được mô tả trong tài liệu n8n. Nếu không có cảnh báo, đối chiếu chế độ chạy và lịch sử execution trước khi cho rằng cấu hình đã hoạt động.

Bước 3: chống trùng ở nơi lưu dữ liệu

Một bước “tìm xem có chưa, nếu chưa thì tạo” có thể vẫn bị trùng khi hai lần chạy đến cùng lúc. Với hệ thống cần đảm bảo chặt chẽ, dùng ràng buộc duy nhất cho mã công việc trong cơ sở dữ liệu hoặc cơ chế idempotency do dịch vụ đích hỗ trợ.

Ghi trạng thái như đang xử lý, hoàn thành và cần đối chiếu theo khả năng của hệ thống. Không đánh dấu hoàn thành trước khi có bằng chứng đầu ra đã tồn tại. Đây là đề xuất kiến trúc; cách thực hiện cụ thể phụ thuộc nơi lưu và API bạn dùng.

Bước 4: kiểm tra số lượng item

Nhiều node n8n xử lý các item đầu vào mà không cần tự tạo vòng lặp. Nếu thấy một thao tác chạy nhiều lần, hãy xem số item trước node và hành vi của node đó. Tự thêm loop có thể làm vấn đề khó đọc hơn. Những node ngoại lệ cần được kiểm tra theo tài liệu riêng.

Bộ tình huống trước khi bật tự động

1. Gửi cùng mã hai lần: có tạo thêm đầu ra không?

2. Gửi hai yêu cầu cùng lúc: nơi lưu có bảo vệ khóa duy nhất không?

3. Làm API đích báo lỗi: có lưu được trạng thái để điều tra không?

4. Mô phỏng timeout sau thao tác ghi: có bước đối chiếu trước retry không?

5. Sửa dữ liệu sai rồi chạy lại: có biết lần chạy nào thay thế lần trước không?

Ghi kết quả thực tế vào phiếu kiểm tra workflow. Các tình huống ở đây là đề bài kiểm tra, chưa phải kết quả triển khai được đo trên hệ thống của Thanhflox.

Nguồn và ảnh

• n8n Error handling: error workflow, Error Trigger và điều kiện thực thi.

• n8n Looping: cách xử lý nhiều item.

• Ảnh minh họa chụp thật: Markus Spiske / Pexels, theo Pexels License. Đây không phải ảnh giao diện n8n.