<!-- Canonical URL: https://ask.atlascloud.ai/vi/replace-replicate-prediction-polling-and-webhooks -->

# Làm thế nào để thay polling và webhook của Replicate Predictions trong ứng dụng hiện có?

> Đặt bản ghi tác vụ bất đồng bộ trung lập với nhà cung cấp giữa sản phẩm và API. Cho webhook đã xác minh hoặc worker polling có giới hạn cập nhật cùng một bộ hoàn tất idempotent, chuẩn hóa trạng thái và chép tệp hoàn tất vào kho bền vững.

Hãy thay polling và webhook của Replicate bằng một lớp tác vụ trung lập với nhà cung cấp giữa ứng dụng và API suy luận. Chuẩn hóa việc tạo, trạng thái, hủy, sự kiện hoàn tất và lưu trữ đầu ra để phần còn lại của sản phẩm không còn phụ thuộc vào đối tượng prediction hoặc URL của Replicate.

Đừng chỉ đổi một URL callback thành URL khác trong mã sản phẩm. Trước tiên, hãy xác định hợp đồng bất đồng bộ mà ứng dụng thực sự cần.

## Ghi lại hành vi hiện tại

Việc tạo bất đồng bộ trên Replicate trả về ID prediction, trạng thái vòng đời và các URL tiện ích. Ứng dụng có thể polling `urls.get`, nhận webhook POST hoặc dùng sự kiện do máy chủ gửi nếu được hỗ trợ. Hãy ghi lại đường đi của từng luồng và hành vi sản phẩm tại mỗi chuyển trạng thái.

| Khái niệm Replicate | Thay thế ở cấp ứng dụng |
|---|---|
| ID prediction | ID tác vụ nhà cung cấp cộng ID tác vụ nội bộ |
| `starting`, `processing` | `queued`, `running` |
| `succeeded` | `completed` |
| `failed`, `canceled` | `failed`, `canceled` |
| `urls.get` | Phương thức trạng thái của adapter |
| Payload webhook | Sự kiện hoàn tất đã chuẩn hóa |
| URL đầu ra | Tài sản bền vững do ứng dụng sở hữu |

Lưu trạng thái thô của nhà cung cấp riêng với trạng thái đã chuẩn hóa. Điều này giữ bằng chứng chẩn đoán khi hai nhà cung cấp có chi tiết vòng đời khác nhau.

## Tạo bản ghi tác vụ nội bộ

Tạo dòng cơ sở dữ liệu trước khi gọi nhà cung cấp mới:

```json
{
  "job_id": "job_01J...",
  "provider": "target",
  "provider_job_id": null,
  "state": "creating",
  "attempt": 1,
  "output_assets": []
}
```

Dùng `job_id` nội bộ trong giao diện, hàng đợi và thông báo. Sau khi tạo thành công, gắn ID tác vụ của nhà cung cấp. Khóa idempotency hoặc token tạo phải ngăn một lần thử lại do lỗi mạng khởi chạy hai tác vụ tính phí.

## Thay polling bằng worker có giới hạn

Nếu API đích cho phép lấy tác vụ nhưng không có webhook, hãy chuyển polling vào worker nền. Dùng backoff lũy thừa có jitter, thời hạn và khoảng cách tối đa. Dừng ở mọi trạng thái cuối, không chỉ thành công và thất bại; hủy cũng phải kết thúc vòng lặp.

Không polling từ trình duyệt. Worker phía máy chủ vẫn chạy sau khi tab đóng, tập trung kiểm soát giới hạn và có thể lưu thay đổi trạng thái theo giao dịch.

## Thay webhook bằng sự kiện đã xác minh

Nếu đích hỗ trợ webhook, hãy giữ handler thật nhỏ:

* xác minh chữ ký hoặc bí mật dùng chung trước khi phân tích dữ liệu;
* loại trùng theo ID sự kiện hoặc ID tác vụ nhà cung cấp cộng trạng thái;
* phản hồi xác nhận nhanh rồi đưa việc xử lý vào hàng đợi;
* lấy lại tác vụ có thẩm quyền khi payload không đầy đủ;
* chấp nhận giao hàng sai thứ tự và lặp lại.

Replicate hỗ trợ bộ lọc sự kiện như start, output, logs và completed. Đích có thể chỉ gửi sự kiện cuối. Chỉ tái tạo báo cáo tiến độ khi thông tin đó có ý nghĩa; không tạo độ chính xác giả từ các trạng thái thưa thớt.

## Dùng một đường hoàn tất duy nhất

Polling và webhook phải gọi cùng một bộ hoàn tất idempotent. Bộ này khóa tác vụ nội bộ, xác nhận ID nhà cung cấp, ghi trạng thái cuối, sao chép tệp đầu ra vào kho bền vững và phát đúng một sự kiện ứng dụng.

Cách này tránh thông báo kép khi webhook và lần polling cuối đến cùng lúc.

## Lưu tệp trước khi chúng biến mất

Tài liệu Replicate nêu rằng tệp đầu vào và đầu ra của prediction qua API tự động bị xóa sau một khoảng thời gian giới hạn. Nhà cung cấp mới có thể có thời gian giữ hoặc tuổi thọ URL ký khác. Hãy coi mọi URL nhà cung cấp là cơ chế giao nhận, không phải kho lưu trữ vĩnh viễn.

Tải đầu ra thành công ngay, xác thực loại nội dung và kích thước, quét nếu cần, lưu dưới khóa do ứng dụng kiểm soát và ghi checksum. Cung cấp URL tài sản ổn định của riêng bạn cho khách hàng.

## Kiểm thử lỗi và khôi phục

Kiểm thử hợp đồng phải bao phủ phản hồi tạo bị trễ, webhook trùng, webhook bị mất, phản hồi polling 429 và 5xx, tranh chấp hủy, URL đầu ra hết hạn, payload sai định dạng và worker khởi động lại giữa tác vụ.

Chạy hai adapter ở chế độ shadow với đầu vào an toàn. So sánh trạng thái cuối và số lượng tài sản trước khi chuyển một tỷ lệ canary của lưu lượng sản xuất.

## Kết luận

Thay thế bền vững cho polling và webhook của Replicate là một hợp đồng tác vụ bất đồng bộ nội bộ, không phải các callback riêng cho nhà cung cấp nằm rải rác trong ứng dụng. Chuẩn hóa trạng thái, làm cho hoàn tất có tính idempotent, lưu tệp ngay và để webhook đã xác minh hoặc worker có giới hạn dẫn động cùng một đường hoàn tất.

## FAQ

### Trình duyệt có nên polling trực tiếp API thay thế không?

Nên dùng worker phía máy chủ. Nó tiếp tục sau khi đóng trình duyệt, tập trung giới hạn và thử lại, đồng thời cập nhật trạng thái nội bộ nhất quán.

### Ánh xạ trạng thái prediction Replicate thế nào?

Ánh xạ sang vòng đời nội bộ nhỏ như creating, queued, running, completed, failed và canceled, đồng thời giữ trạng thái thô để chẩn đoán.

### Làm sao tránh xử lý webhook hai lần?

Xác minh nguồn, loại trùng theo sự kiện hoặc tác vụ và trạng thái, rồi đưa webhook và polling vào cùng bộ hoàn tất idempotent có giao dịch.

### Nếu nhà cung cấp mới không có webhook thì sao?

Dùng worker nền có backoff lũy thừa, jitter, hạn chót và xử lý rõ ràng mọi trạng thái cuối.

### Có thể hiển thị vĩnh viễn URL đầu ra của nhà cung cấp không?

Không nên giả định chúng bền vững. Tải đầu ra sớm và cung cấp URL tài sản của ứng dụng với kiểm soát truy cập riêng.

### Cần kiểm thử những lỗi nào?

Kiểm thử sự kiện trùng hoặc mất, giới hạn, lỗi tạm thời, tranh chấp hủy, đầu ra hết hạn, payload sai và worker khởi động lại.