BÁO CÁO SỰ CỐ: PAGE KHÔNG ĐƯỢC ĐĂNG BÀI SÁNG 14/09/2026

• Ngày: 14/09/2026 (Thứ Hai)
• Người xử lý: Admin dự án Bún Bò Huế Chú Mập (@hp_chumap_bot)
• Page: Bún Bò Huế Chú Mập — ID 970213406179611
• Yêu cầu của Anh: "sáng giờ bị gì mà không post facebook vậy em"

1. TÌNH TRẠNG THỰC TẾ KHI KIỂM TRA (số liệu thật, không đoán)

• Feed page lấy trực tiếp qua Graph API: bài mới nhất là 13/09 lúc 19:00. Suốt buổi sáng 14/09 page TRỐNG — không có bài 07h và 11h.
• Lịch 13/09 cũng đã hụt 1 khung (chỉ có 3/4 bài, thiếu khung 11h).
• Instance RIÊNG của dự án (n8n-chumap, port 5682): workflow content chumapNgay9WF01 đang ở trạng thái TẮT (active=0, activeVersionId=NULL) → không đăng được.
• Instance CHUNG (n8n, port 5678): workflow content vẫn bật, nhưng container lỗi SQLITE_IOERR: disk I/O error liên tục trong log và 0 execution trong cả ngày 14/09 (kể cả các workflow khác của instance này) → trigger lịch không bắn.

2. NGUYÊN NHÂN GỐC

Hai đường đăng bài cùng hỏng một lúc:

1. Đường đang chạy thật (workflow content trên instance CHUNG 5678) chết vì lỗi đọc/ghi database SQLite của instance chung → n8n không chạy được schedule trigger → không đăng.
2. Đường dự phòng của dự án (workflow content trên instance RIÊNG 5682) lại đang bị tắt → không có gì đăng thay.

Kết quả: khung 07h và 11h ngày 14/09 không đăng bài nào.

3. ĐÃ XỬ LÝ XONG TRONG SÁNG NAY

1. Bật lại workflow content trên instance RIÊNG 5682 (đúng chủ trương "không sài chung"):
2. Backup database trước khi sửa: database.sqlite.bak-20260914-125940.
3. Phát hiện: gọi REST activate trả về 200 nhưng DB không lưu (workflow chưa từng có bản publish) → sửa thẳng DB: active=1 + activeVersionId = bản mới nhất trong workflow_history, rồi docker restart n8n-chumap.
4. Xác nhận bằng log container: Activated workflow "Content Chu Map - CACH LAM NGAY 9 (7-11-17-19h)" → đã bật thật.
5. Đăng bù khung 11h ngay: bài thật đã lên page lúc 12:47 ngày 14/09, is_published = true:
6. Nội dung: "🍜 TRƯA NAY ĂN GÌ? GHÉ CHÚ MẬP NHA"
7. Link: https://www.facebook.com/122116987377280694/posts/122123412387280694
8. Execution trên 5682: id 629, status success (05:47:50 → 05:47:57 UTC).
9. Dựng lưới an toàn để không bao giờ mất bài im lặng nữa:
10. Script chumap-bu-content.py: mỗi lần chạy kiểm tra đủ 4 khung 07/11/17/19h hôm nay (đọc thẳng feed page); khung gần nhất đã qua hơn 25 phút mà chưa có bài → tự đăng bù và nhắn Anh biết; bình thường thì im lặng (không làm phiền Anh).
11. Cron CHUMAP-Bu-Content-20p — chạy mỗi 20 phút, 7h–21h mỗi ngày; có chốt chống đăng bù trùng 2 lần cho cùng một khung.
12. Đã test: chạy lúc 13:05 → im lặng, không đăng trùng (đúng vì khung 11h đã có bài).

4. CÒN LẠI / XIN Ý ANH

1. Khung 07h hôm nay em KHÔNG đăng bù (để tránh 2 bài sát nhau giữa trưa). Anh muốn bù thì em chạy ngay.
2. Bản workflow content trên instance CHUNG 5678 vẫn đang BẬT → khi instance chung hồi phục, nó sẽ đăng TRÙNG với bản riêng 5682. Em xin phép Anh cho tắt workflow này ở instance chung (đây là workflow CỦA dự án mình). Em chưa tự làm vì instance chung không phải tài nguyên riêng của em.
3. Instance chung 5678 đang bệnh SQLITE_IOERR — việc này ảnh hưởng cả các workflow khác trên đó (không thuộc dự án mình), em chỉ báo để Anh/biết mà xử, không đụng vào.
4. Khung 17h và 19h hôm nay sẽ tự chạy trên instance riêng 5682; nếu lỡ, watchdog sẽ tự đăng bù và báo Anh.

5. CAM KẾT

• Content vẫn làm y như ngày 09/09 (7h·11h·17h hình + 19h clip; 1 tô + 1 topping; món xoay vòng theo menu).
• Chỉ dùng hình/clip có sẵn trong kho SATA — không tạo ảnh/clip AI, không bán món ngoài menu.
• Mọi bài đều có thẻ địa điểm (bài ảnh/chữ) và chân trang chuẩn.
• Từ nay mất bài là watchdog báo ngay, không để Anh phải phát hiện giúp.