Harnix

Checklist trước khi lên production

Những việc cần kiểm tra trước khi phát hành tích hợp.

Xác thực & credential

  • API key chỉ nằm ở backend của bạn — grep code frontend đã build để chắc chắn nó không lọt vào bundle JavaScript.
  • Nếu dùng danh tính có ký (user-hash), identity_secret chỉ nằm ở backend, expires_at không quá 24 giờ kể từ lúc ký, và bạn ký lại mỗi lần phát hành trang (không cache chữ ký lâu hơn cần thiết).
  • Origin được phép (Console → Tích hợp) liệt kê đúng domain production của bạn — không phải localhost. Kiểm tra cả www. và không www. nếu trang bạn phục vụ cả hai.
  • Nếu dùng token-url, endpoint đó tự xác thực người gọi (session cookie, hoặc tương đương) trước khi gọi POST /v2/token — nó không phải một proxy mở cho bất kỳ ai gọi.

Xử lý lỗi

  • Lập trình theo code, không theo message (xem Lỗi) — message có thể đổi mà không cảnh báo trước.
  • Xử lý rate_limited bằng cách đợi retry_after giây rồi thử lại, không retry ngay lập tức.
  • Xử lý budget_exceeded bằng một thông báo rõ ràng cho end-user ("dịch vụ tạm thời quá tải") thay vì một lỗi chung chung.
  • redis_unavailable trên endpoint stream không có nghĩa là câu trả lời bị mất — poll lại conversation, đừng báo lỗi cho người dùng.

Streaming

  • Xử lý kết nối rớt giữa chừng: gọi lại đúng GET /v2/runs/{run_id}/stream, đừng gửi lại message.
  • Bỏ qua mọi dòng SSE bắt đầu bằng : (dòng keepalive) thay vì coi đó là lỗi parse.
  • Không dùng EventSource gốc của trình duyệt nếu bạn cần header Authorization — xem Streaming.

Giới hạn & idempotency

  • Gửi Idempotency-Key trên mọi lời gọi gửi message, đặc biệt nếu client của bạn có thể tự động retry khi timeout.
  • Trần 3 run đang chạy cùng lúc mỗi end-user không phải bug — nếu UI của bạn cho phép gửi nhiều message dồn dập, disable input trong lúc đợi run trước kết thúc, hoặc xử lý scope: "active_runs" một cách rõ ràng.

Vận hành

  • Xem lại Mức sử dụng và Hạn mức & giới hạn trong console trước khi launch — đặt ngân sách token hợp lý cho tổ chức/agent nếu bạn muốn một trần chi phí cứng.
  • Biết cách đọc Lượt chạy (và trace của nó) trong console để debug một câu trả lời sai — mọi tool call, mọi trích dẫn đều xem lại được.
  • Có kế hoạch cho việc chặn hoặc xoá một end-user (Console → Người dùng cuối) nếu sản phẩm bạn cần điều đó (spam, yêu cầu xoá dữ liệu).

Trên trang này