n8n + WordPress API: retry publish khi ảnh hoặc category bị lỗi và ghi log về Telegram

Blueprint thực chiến để thiết kế workflow n8n + WordPress API có retry theo từng chặng, tránh trùng bài, đủ ảnh và log lỗi về Telegram/NocoDB.

Ở bài trước, chuỗi Content Ops đã đi từ NocoDB Content Approval Hub đến case study trung tâm đào tạo: làm sao để đội sales chỉ dùng nội dung đã duyệt. Bước tiếp theo dành cho slot tối là phần kỹ thuật hơn: khi automation tự động đăng bài lên WordPress, điều gì xảy ra nếu ảnh lỗi, category sai, slug bị trùng, hoặc API trả về lỗi giữa chừng?

Nhiều đội bắt đầu bằng một workflow n8n rất đơn giản: lấy bản nháp từ NocoDB, tạo ảnh, upload media, rồi gọi WordPress REST API để publish. Luồng đó chạy tốt trong demo, nhưng khi dùng hằng ngày sẽ gặp các tình huống khó chịu: ảnh tạo quá lâu, WordPress timeout, tag chưa tồn tại, category bị xoá, bài đã được tạo nhưng n8n tưởng là thất bại, hoặc Telegram báo lỗi mà không đủ thông tin để sửa. Bài này đưa ra một blueprint thực chiến để thiết kế cơ chế retry publish an toàn cho n8n + WordPress API, đồng thời ghi log lỗi về Telegram và NocoDB.

Vấn đề: publish tự động không chỉ là một lệnh POST

Nếu chỉ nhìn API, việc đăng bài có vẻ đơn giản: gọi POST /wp-json/wp/v2/posts với title, content, status, category, tag và featured media. Nhưng trong hệ thống thật, bài viết là kết quả của nhiều bước phụ thuộc lẫn nhau. Ảnh phải tạo xong trước khi upload. Media phải upload xong trước khi set featured image. Category và tag phải hợp lệ trước khi publish. Slug không nên trùng với bài đã có. Nội dung phải có đủ ảnh inline, CTA và excerpt trước khi gửi.

Một lỗi ở bước đầu có thể tạo hậu quả ở bước sau. Ví dụ, token tạo ảnh trả lỗi tạm thời, n8n retry toàn bộ workflow từ đầu và vô tình tạo hai bản nháp giống nhau. Hoặc WordPress đã tạo post thành công nhưng response timeout, n8n không nhận được ID bài viết, sau đó chạy lại và tạo bài thứ hai với slug gần giống. Với site nội dung như quanchatbot.com, lỗi này không chỉ gây rối vận hành mà còn ảnh hưởng SEO vì trùng chủ đề, trùng canonical nội bộ hoặc bài thiếu ảnh.

Kiến trúc nên có: NocoDB giữ trạng thái, n8n điều phối, Telegram cảnh báo

Để workflow bền hơn, hãy tách rõ ba vai trò. NocoDB là nơi lưu bản ghi bài viết, trạng thái publish, số lần retry, lỗi gần nhất và ID bài WordPress nếu đã tạo. n8n là lớp điều phối: đọc record, kiểm tra điều kiện, tạo ảnh, upload media, gọi WordPress API, verify lại bài đã publish. Telegram là kênh cảnh báo nhanh cho người vận hành khi có lỗi cần can thiệp.

Bảng NocoDB tối thiểu nên có các trường:

• content_id: mã duy nhất cho mỗi bài, dùng làm idempotency key.
• title, slug, pillar, status: trạng thái nội dung.
• wp_post_id, wp_url, featured_media_id: kết quả sau khi đăng.
• image_status, media_status, publish_status: tách lỗi theo từng chặng.
• retry_count, last_error, last_run_at, next_retry_at.
• payload_hash: dấu vết để biết nội dung có thay đổi thật hay chỉ workflow chạy lại.

Khi có bảng trạng thái rõ ràng, n8n không cần đoán “lần trước đã chạy tới đâu”. Workflow có thể tiếp tục từ bước dang dở: ảnh đã có thì không tạo lại; media đã upload thì không upload lại; bài đã publish thì chỉ verify và cập nhật log.

Thiết kế retry theo từng chặng, không retry mù toàn bộ workflow

Sai lầm phổ biến là bọc toàn bộ workflow trong một cơ chế retry chung. Cách này dễ tạo trùng ảnh, trùng media và trùng post. Thay vào đó, hãy chia luồng thành các chặng có trạng thái riêng.

Chặng 1: chuẩn bị dữ liệu

n8n đọc bản ghi từ NocoDB, kiểm tra title, slug, category, tag, excerpt, nội dung HTML và danh sách ảnh cần tạo. Nếu thiếu dữ liệu bắt buộc, đừng gọi WordPress. Hãy cập nhật publish_status = needs_fix và gửi Telegram cho người phụ trách nội dung.

Chặng 2: tạo và lưu ảnh

Với mỗi ảnh, lưu filename, prompt, trạng thái, media ID nếu đã upload. Nếu API ảnh lỗi tạm thời, retry riêng ảnh đó một lần. Nếu vẫn lỗi, dừng trước khi publish. Không nên đăng bài thiếu ảnh nếu quy trình yêu cầu đủ featured image và ảnh minh hoạ.

Chặng 3: upload media

Trước khi upload, kiểm tra trong NocoDB đã có media ID chưa. Nếu có, gọi GET media để verify. Nếu media còn tồn tại, dùng lại. Nếu media bị xoá, đánh dấu cần upload lại. Sau khi upload, cập nhật alt text và đọc lại media để chắc chắn URL và alt text đã đúng.

Chặng 4: publish post

Trước khi gọi POST /posts, kiểm tra wp_post_id. Nếu đã có, không tạo bài mới; chuyển sang verify. Nếu chưa có, kiểm tra slug trong 20-50 bài gần nhất hoặc gọi endpoint search để giảm nguy cơ trùng. Sau khi POST thành công, ghi ngay post ID vào NocoDB trước khi làm bước khác.

Chặng 5: verify sau publish

Gọi GET post bằng ID vừa tạo, kiểm tra status=publish, featured media đúng, nội dung có đủ ảnh inline, link tồn tại. Chỉ khi verify đạt mới đánh dấu publish_status = done.

Mapping lỗi WordPress API thành hành động cụ thể

Không phải lỗi nào cũng nên retry giống nhau. Một workflow tốt cần phân loại lỗi:

• 401/403: lỗi credential hoặc quyền application password. Dừng ngay, báo Telegram mức khẩn cấp, không retry liên tục.
• 404 category/media/post: dữ liệu tham chiếu không tồn tại. Cần refresh category/tag hoặc upload lại media.
• 400 invalid parameter: payload sai, thường cần sửa dữ liệu hoặc format HTML.
• 408/429/500/502/503/504: lỗi tạm thời hoặc quá tải. Có thể retry với backoff.
• timeout không rõ kết quả: phải tra lại bằng slug, payload hash hoặc post title trước khi quyết định tạo mới.

Điểm nguy hiểm nhất là timeout sau khi WordPress đã tạo bài nhưng n8n chưa nhận response. Với trường hợp này, workflow nên gọi GET theo slug hoặc search title trước. Nếu tìm thấy bài đã publish và nội dung khớp, cập nhật wp_post_id vào NocoDB thay vì tạo lại.

Gửi log lỗi về Telegram sao cho sửa được ngay

Một tin nhắn Telegram tốt không chỉ nói “workflow lỗi”. Nó phải đủ ngữ cảnh để người vận hành biết mở đâu, sửa gì, có cần chạy lại không. Nội dung nên gồm:

• Tên workflow và môi trường: production, staging hoặc test.
• content_id, title, slug và link record NocoDB.
• Bước lỗi: generate_image, upload_media, ensure_category, publish_post, verify_post.
• Mã lỗi HTTP hoặc message rút gọn, không chứa secret.
• retry_count và next_retry_at.
• Hành động gợi ý: kiểm tra credential, sửa category, tạo lại ảnh, hoặc bấm chạy lại record.

Nếu dùng Telegram nhiều, nên phân mức cảnh báo: warning cho retry tạm thời, error cho lỗi cần sửa dữ liệu, critical cho auth hoặc nguy cơ tạo trùng bài. Như vậy nhóm vận hành không bị “chai lì” vì quá nhiều thông báo giống nhau.

Idempotency: chìa khóa để không tạo trùng bài

Idempotency nghĩa là cùng một sự kiện chạy lại nhiều lần nhưng kết quả cuối vẫn chỉ có một bài đúng. Với WordPress API, bạn có thể thiết kế idempotency bằng ba lớp:

1. content_id trong NocoDB: mỗi bản ghi chỉ được phép sinh một wp_post_id.
2. slug ổn định: slug tạo từ title đã duyệt, không thay đổi tuỳ tiện giữa các lần chạy.
3. payload_hash: hash của title, content, media ID, category, tag để biết payload có đổi hay không.

Khi workflow bắt đầu, bước đầu tiên là kiểm tra content_id. Nếu đã có wp_post_id, workflow không gọi POST tạo bài nữa. Nếu không có nhưng slug đã tồn tại trên WordPress, workflow cần quyết định: đó có phải bài của record này không? Nếu có dấu vết trong NocoDB hoặc title khớp, cập nhật lại ID; nếu không, tạo slug mới có hậu tố hợp lý và ghi rõ trong log.

Checklist triển khai n8n + WordPress API bền hơn

• [ ] Có bảng NocoDB lưu trạng thái từng chặng: draft, image_ready, media_uploaded, publishing, published, failed, needs_fix.
• [ ] Mỗi bài có content_id và slug ổn định trước khi publish.
• [ ] Không retry toàn bộ workflow nếu chỉ một ảnh lỗi.
• [ ] Sau upload media, cập nhật alt text và GET lại media để verify.
• [ ] Trước POST /posts, kiểm tra bài đã tồn tại theo wp_post_id hoặc slug.
• [ ] Sau publish, GET lại post và kiểm tra status, featured_media, số ảnh inline.
• [ ] Telegram log có đủ bước lỗi, mã lỗi, record URL và hướng xử lý.
• [ ] 401/403 dừng ngay, không retry vòng lặp.
• [ ] Timeout sau POST phải search lại trước khi tạo bài mới.
• [ ] Có lịch dọn bản ghi failed cũ và dashboard theo dõi lỗi lặp lại.

Ví dụ luồng retry thực tế

Giả sử record trong NocoDB có trạng thái approved và sẵn sàng đăng. n8n bắt đầu bằng cách đổi trạng thái sang publishing, tạo payload hash và kiểm tra slug. Ảnh featured tạo thành công, nhưng ảnh minh hoạ thứ ba bị lỗi timeout. Workflow retry riêng ảnh đó một lần. Nếu lần hai thành công, tiếp tục upload media. Nếu vẫn lỗi, cập nhật image_status = failed, publish_status = failed, ghi last_error và gửi Telegram. Bài chưa được tạo trên WordPress, vì điều kiện đủ ảnh chưa đạt.

Ở lần chạy sau, workflow thấy hai ảnh đầu đã có file local hoặc media ID, nên không tạo lại. Nó chỉ tiếp tục từ ảnh thứ ba. Khi đủ media, workflow gọi POST /posts. Nếu WordPress trả timeout, workflow không vội tạo lại. Nó search slug. Nếu thấy bài đã publish, ghi post ID vào NocoDB và chuyển sang verify. Nếu không thấy, mới retry POST với cùng slug và cùng payload.

Cách làm này chậm hơn một workflow demo vài bước, nhưng đáng tin hơn nhiều khi chạy hằng ngày.

Lưu ý vận hành và sai lầm thường gặp

Đừng đưa secret vào log

Log Telegram chỉ nên có mã lỗi, endpoint rút gọn và message đã lọc. Không gửi application password, bearer token hoặc full header.

Đừng tạo quá nhiều tag tự động

WordPress tag nên được kiểm soát. Nếu workflow tự tạo tag từ mọi keyword, site sẽ nhanh chóng có hàng trăm tag rác. Hãy dùng danh sách tag cho phép hoặc yêu cầu duyệt tag mới.

Đừng publish nếu ảnh bắt buộc chưa đủ

Với bài SEO có yêu cầu featured image và ảnh minh hoạ, đăng thiếu ảnh làm trải nghiệm đọc kém và mất thời gian chỉnh sửa thủ công. Tốt hơn là fail sớm và báo lỗi rõ.

Đừng bỏ qua verify sau publish

POST thành công chưa chắc bài đã đúng. Verify là bước xác nhận bài thật sự publish, link mở được, featured media đúng và nội dung có đủ block quan trọng.

FAQ

1. Có nên dùng Google Sheets thay NocoDB để lưu trạng thái publish không?

Có thể dùng Google Sheets khi workflow nhỏ. Nhưng khi cần API ổn định, bảng liên kết media/post/log, phân quyền và nhiều view vận hành, NocoDB phù hợp hơn để làm lớp dữ liệu cho content ops.

2. Retry bao nhiêu lần là đủ?

Với lỗi tạm thời như 502 hoặc timeout, có thể retry 2-3 lần với backoff. Với lỗi dữ liệu như category sai, payload invalid hoặc credential sai, nên dừng và báo người vận hành.

3. Có nên để n8n tự sửa slug khi trùng không?

Có thể, nhưng cần ghi lại slug cuối cùng vào NocoDB và Telegram log. Nếu trùng vì bài đã được tạo ở lần chạy trước, không nên tạo slug mới mà phải liên kết lại đúng post ID.

4. Làm sao biết bài thiếu ảnh inline?

Sau publish, gọi GET post và kiểm tra content rendered hoặc block structure. Nếu yêu cầu có 4 ảnh minh hoạ, workflow nên đếm số thẻ img/figure tương ứng trước khi đánh dấu done.

5. Khi nào cần tách workflow tạo ảnh khỏi workflow publish?

Khi ảnh tạo lâu, dễ timeout hoặc cần duyệt riêng, nên tách thành hai workflow. Workflow publish chỉ chạy khi mọi media đã sẵn sàng và đã được verify.

Kết luận

Tự động publish WordPress bằng n8n không khó, nhưng để chạy bền hằng ngày cần thiết kế như một quy trình vận hành: có trạng thái, có idempotency, có retry theo từng chặng, có verify sau publish và có log Telegram đủ ngữ cảnh. Khi NocoDB giữ vai trò nguồn sự thật, n8n điều phối cẩn thận và WordPress chỉ nhận payload đã sẵn sàng, đội nội dung có thể mở rộng sản xuất bài SEO mà vẫn giảm rủi ro trùng bài, thiếu ảnh hoặc lỗi âm thầm.

Nếu bạn muốn triển khai hệ thống automation tương tự cho doanh nghiệp, hãy liên hệ Quân Chatbot để được tư vấn giải pháp phù hợp.