Lịch sử tự động hóa của bạn hiển thị một lần chạy thành công và một gói đầu ra. Facebook hiển thị hai bài viết.

Bằng chứng đó loại trừ một số lời giải thích đơn giản, nhưng nó không chứng minh được hệ thống nào đã sao chép bản ghi. Đừng chạy tự động hóa nữa. Lưu giữ cả provider original và tạo một dòng bằng chứng cho mỗi bài viết có thể được gửi tới Facebook.

Danh sách kiểm tra này bao gồm trường hợp cụ thể trong đó quy trình làm việc của Airtable, Make, n8n hoặc tùy chỉnh dường như chạy một lần trong khi Trang Facebook nhận được các bài đăng trùng lặp.

Câu trả lời ngắn gọn

Trước khi thay đổi kịch bản, hãy ghi lại:

  1. ID thực thi tự động hóa và thời gian bắt đầu/kết thúc chính xác
  2. mọi gói đầu vào hoặc ID bản ghi nguồn
  3. thử lại, lịch sử thực thi chưa hoàn tất và thời gian chờ
  4. mọi ID bài đăng trên Facebook và liên kết cố định
  5. dấu thời gian công khai và nội dung hiển thị của mỗi bài đăng

Nếu hai bài đăng trên Facebook có provider ID khác nhau thì sẽ có hai lần tạo từ phía nhà cung cấp ngay cả khi giao diện người dùng tự động hóa tóm tắt công việc dưới dạng một lần chạy. Câu hỏi còn lại là quá trình tạo thứ hai bắt nguồn từ đâu: một trình kích hoạt khác, một lần thử lại tự động, một quá trình khôi phục hết thời gian chờ, một bản sao phía nhà cung cấp hoặc một ứng dụng khách riêng biệt sử dụng cùng một bản ghi nguồn.

Đừng dán nhãn nguyên nhân cho đến khi có bằng chứng phân biệt được những con đường đó.

1. Trước tiên hãy bảo quản cả bản gốc công khai

Mở cả hai bài đăng trên Facebook trước khi xóa hoặc chỉnh sửa một trong hai bài đăng. Đối với mỗi bài đăng, hãy chụp:

  • Nhận dạng trang
  • ID bài đăng của nhà cung cấp
  • liên kết cố định
  • dấu thời gian được xuất bản
  • chú thích và phương tiện chính xác
  • bất kỳ tác giả hoặc quyền xuất bản rõ ràng nào

So sánh dấu vân tay văn bản và phương tiện. Hai chú thích giống nhau không chứng minh được rằng cùng một yêu cầu đã được phát lại; hai khách hàng độc lập có thể gửi cùng một bản ghi nguồn. Hai provider ID khác nhau chứng minh rằng nhà cung cấp đã chấp nhận hai lần tạo.

Nếu chỉ có một liên kết cố định và bài đăng thứ hai vẫn hiển thị, hãy giữ lại ảnh chụp màn hình và dấu thời gian công khai trong khi bạn điều tra. Đánh dấu ID bị thiếu là unknown.

2. Tách biệt việc chạy kịch bản khỏi việc ghi của nhà cung cấp

Quá trình chạy tự động hóa xanh có nghĩa là việc điều phối được hoàn thành theo quy tắc của nền tảng đó. Nó không nhất thiết có nghĩa là một lần ghi bên ngoài đã xảy ra.

Tạo các tài liệu có thể thử lại các lỗi kết nối, giới hạn tốc độ và thời gian chờ thông qua việc thực thi không đầy đủ và thời gian chờ theo cấp số nhân. Tài liệu của nó cũng lưu ý rằng không thể khôi phục các hành động trong ứng dụng bên ngoài không có giao dịch. Do đó, việc tạo nhà cung cấp có thể thành công ngay cả khi khách hàng sau đó hết thời gian chờ hoặc mất phản hồi.

Kiểm tra những điều này một cách riêng biệt:

Lớp Bằng chứng cần thu thập Nó có thể chứng minh điều gì
Kích hoạt lịch trình/thời gian webhook và ID kích hoạt đã bắt đầu bao nhiêu lần chạy
Nguồn ID bản ghi Airtable và số lượng gói đầu vào có bao nhiêu bản ghi được đưa vào luồng
Tạo mô-đun hoạt động của mô-đun, thời gian bắt đầu/kết thúc, đầu ra thô có bao nhiêu nhà cung cấp gọi nền tảng được ghi lại
Thử lại hệ thống thực thi không đầy đủ, thử lại tự động, lịch sử chờ đợi cuộc gọi không thành công hoặc không rõ ràng có chạy lại hay không
Facebook mỗi ID bài đăng và permalink có bao nhiêu đối tượng nhà cung cấp công cộng tồn tại

Đừng thu gọn năm hàng này thành “cuộc chạy đã thành công”.

3. Kiểm tra các yếu tố kích hoạt thứ hai ẩn

Trước khi đổ lỗi cho Facebook, hãy loại bỏ những nguyên nhân bạn có thể kiểm soát:

  • một kịch bản khác được lên lịch sử dụng cùng một Trang
  • webhook tức thì cộng với tìm kiếm hàng giờ
  • không gian làm việc, môi trường thứ hai hoặc kịch bản cũ
  • hai bản ghi nguồn có cùng nội dung
  • bài đăng thủ công được tạo từ Trang hoặc Business Suite
  • cửa sổ thăm dò chọn lại bản ghi trước khi cập nhật trạng thái của nó hiển thị

Sử dụng số nhận dạng ổn định, không chỉ dấu thời gian. Ghi lại ID kịch bản tự động hóa, ID bản ghi nguồn, dấu vân tay nội dung và ID trang đích trong cùng một hàng.

Nếu hai quy trình công việc chia sẻ một bảng nguồn, hãy thêm yêu cầu hoặc khóa dành riêng cho đích đến trước khi nhà cung cấp tạo. Chỉ riêng bộ đệm thời gian không phải là sự đảm bảo về tính bình thường.

4. Hãy coi phản hồi chậm là mơ hồ

Một mô-đun Facebook chạy lâu là bằng chứng quan trọng nhưng bản thân nó không xác định được nguyên nhân.

Nếu nhà cung cấp chấp nhận bài đăng và khách hàng đã hết thời gian chờ trước khi nhận được phản hồi, thì việc thử lại tự động có thể tạo một bài đăng khác trừ khi quá trình tích hợp đối chiếu kết quả đầu tiên. Nếu mô-đun trả về một provider ID trong khi tồn tại hai bài đăng, hãy giữ lại ID bài đăng chưa khớp và hỏi tác nhân nào đã tạo nó.

Quy tắc an toàn là:

Hết thời gian chờ hoặc mất phản hồi là unknown chứ không phải failed cho đến khi đích đến được chọn.

Tạm dừng quá trình khôi phục tự động cho đích đó khi đã tồn tại bất kỳ provider ID nào hoặc bài đăng công khai phù hợp.

5. Xây dựng sổ cái bằng chứng gồm hai bài

Sử dụng một hàng cho mỗi đối tượng nhà cung cấp:

destination_page_id:
source_record_id:
automation_execution_id:
create_module_operation_id:
retry_or_incomplete_execution_id:
provider_post_id:
provider_permalink:
provider_timestamp:
content_fingerprint:
public_outcome:
observed_in_automation_output: yes | no | unknown

Đối với hai bài đăng trên Facebook, sổ cái phải chứa hai hàng ngay cả khi nền tảng tự động hóa hiển thị một lần chạy. Các lĩnh vực chưa từng có cho thấy nơi điều tra cần bằng chứng mạnh mẽ hơn.

6. Thêm cổng khôi phục ở phạm vi đích

Trước khi tạo hoặc thử lại, hãy kiểm tra bản ghi hiện có cho Trang đó:

  1. Đã có ID bài đăng của nhà cung cấp chưa?
  2. Có liên kết cố định được lưu trữ không?
  3. Trang công khai có chứa dấu vân tay nội dung phù hợp trong khoảng thời gian dự kiến ​​không?
  4. Việc thực thi chưa hoàn tất vẫn đủ điều kiện để thử lại mô-đun tạo phải không?

Khi kết quả không rõ ràng, hãy chuyển mục sang điều chỉnh thủ công thay vì tạo lại. Khi lô đa kênh thành công một phần, chỉ thử lại đích chưa được giải quyết sau khi kiểm tra trạng thái nhà cung cấp của chính nó.

Cổng này không đảm bảo rằng mọi nhà cung cấp đều hiển thị khóa tạm thời. Nó ngăn logic khôi phục của bạn coi xác nhận máy khách bị thiếu là bằng chứng cho thấy không có gì được tạo.

Cảnh báo thành công một phần thực sự từ một mạng khác

Trong một sự cố ANKK Threads riêng biệt, một root theo lịch trình đã được xuất bản và bước trả lời gặp phải kết quả không có sẵn của nhà cung cấp. Quá trình khôi phục tự động tạo ra hai câu trả lời công khai giống hệt nhau mặc dù người vận hành không thử lại theo cách thủ công. provider original, nội dung ổn định và job ID đã được lưu giữ để điều tra sản phẩm.

Sự cố Threads đó không chứng minh được nguyên nhân gây ra sự trùng lặp trên Facebook. Nó thể hiện ranh giới lỗi chung: khi bất kỳ phân đoạn nào có thể đã đến tay nhà cung cấp, việc khôi phục cần sự đối chiếu của nhà cung cấp tại phân đoạn đó thay vì lặp lại toàn bộ hoạt động một cách mù quáng.

Nguồn và các bước tiếp theo

Tôi điều hành ANKK. ANKK không bao gồm trình ghi AI tích hợp. Nó kết nối nội dung do con người chuẩn bị, các công cụ AI bên ngoài hoặc tập lệnh với lịch trình xã hội, trạng thái cấp kênh và xác minh ban đầu của nhà cung cấp.

Xem lại quy trình làm việc của nhà phát triển ANKK