Hướng dẫn
Vòng đời job, trạng thái, retry & backoff, và cách kích worker.
Mỗi lần Averosi giao dữ liệu — tới Telegram, Sheets, HubSpot, hay một webhook bất kỳ — đều để lại dấu vết: một event trong luồng sự kiện, một job kèm trạng thái, và (nếu cứ lỗi mãi) một event sync_failed để bạn xử lý. Giám sát là nơi bạn theo dõi dấu vết đó và retry những gì chưa về đích.
Trang được render phía server từ dữ liệu Supabase trực tiếp — không cần refresh hay polling gì cả. Bốn khối, từ trên xuống:
sync_jobs gần nhất — mỗi dòng ứng với một cặp (event, đích đến) — kèm trạng thái, số lần thử, lỗi gần nhất, và nút Retry. Bạn có thể chọn nhiều job dead/failed để retry hàng loạt.lead_created, order_paid, sync_failed, v.v.) kèm kênh nguồn và campaign khớp được.Khi một canonical event phát sinh, Averosi fan-out nó thành nhiều dòng sync_jobs — mỗi đích đến đang kết nối một dòng (xem Khái niệm cốt lõi để hiểu mô hình event → job). Mỗi job đi qua một tập trạng thái cố định:
| Trạng thái | Ý nghĩa |
|---|---|
pending | Đang xếp hàng, chờ tới next_run_at. |
processing | Worker đã claim (khóa dòng bằng FOR UPDATE SKIP LOCKED) và đang giao lúc này. |
succeeded | Đã giao thành công. last_sync_at của connection liên quan được cập nhật. |
failed | Giao thất bại nhưng vẫn retry được và còn lượt thử — hiển thị Retrying trên UI. Sẽ backoff rồi tới hạn lại sau. |
dead | Giao thất bại và lỗi không thể retry, hoặc attempts ≥ max_attempts. Một event sync_failed được ghi lại nên sẽ xuất hiện trong luồng sự kiện. Trạng thái này đứng yên cho tới khi bạn tự retry. |
Chỉ những job pending và failed đã tới hạn (next_run_at) mới được worker nhặt lên. Mỗi lần lỗi, thời gian chờ trước lần thử kế tiếp tăng gấp đôi: 30s × 2^(attempts − 1), trần ở 1 giờ. Vậy một job thường thử lại quãng 30 giây, 1 phút, 2 phút, 4 phút... cho tới trần, cho đến khi đạt max_attempts thì chuyển dead.
Một job dead hoặc failed không bao giờ tự biến mất — nó vẫn hiển thị kèm lỗi gần nhất cho tới khi bạn xử lý. Bấm Retry ở từng dòng, hoặc chọn nhiều dòng bằng checkbox rồi dùng thanh retry hàng loạt. Retry sẽ đặt lại attempts về 0, xóa last_error, đặt next_run_at về hiện tại, và chuyển trạng thái về pending — lần worker chạy tiếp theo sẽ xử lý nó như một job mới.
Lỗi và cảnh báo
Mọi lỗi cuối cùng (terminal) đều tạo thêm một canonical event sync_failed trong Event Stream, và mọi thay đổi trạng thái (enqueued, succeeded, failed, dead, retried) đều được ghi vào audit log — đó chính là dữ liệu nuôi số Active Alerts trên dải chỉ số sức khỏe.
Bạn không cần tự kích gì cả. Việc giao dữ liệu chạy nền theo lịch riêng, tự retry với backoff như mô tả ở trên — một lead thường được giao trong vòng một phút kể từ khi tới. Nếu một job cần thúc thêm, dùng nút Retry trên màn hình Giám sát — đó là thao tác duy nhất bạn cần làm.
Bắn Test Webhook xong không thấy gì xảy ra
Nếu một lead thử nghiệm đứng yên ở trạng thái Pending hơn vài phút mà không nhúc nhích, có gì đó không ổn. Xem Khắc phục sự cố để có checklist đầy đủ.
Vẫn chưa giải quyết được?
Nếu tài liệu chưa đề cập, hãy mở trang Hỗ trợ.