Điểm nổi bật
Các phản hồi vượt quá hạn mức hiện trả về HTTP 429 với header Retry-After, khớp với những gì OpenAI, GitHub và Cloudflare gửi. Trang định giá có thêm hàng Băng thông (mọi gói công khai đều là Không giới hạn). Và các request yêu cầu exitCountries trên một gói không có tính năng nhắm mục tiêu theo vị trí địa lý (geo-targeting) hiện nhận được lỗi 403 rõ ràng nêu tên tham số và cách khắc phục.
Có gì mới
Giới hạn hạn mức hiện sử dụng HTTP 429, không phải 402
Nếu bạn chạm tới giới hạn của gói (tín dụng hoặc băng thông), phản hồi sẽ là 429 Too Many Requests với Retry-After trên mọi reply và resets_at trong phần body trỏ đến thời điểm kết thúc chu kỳ thanh toán của bạn. Trường reason cho bạn biết giới hạn nào bạn đã chạm tới (plan_limit_credits hoặc plan_limit_bandwidth) để nó không xung đột với các rate limit mỗi phút.
Tại sao lại có sự thay đổi này? 402 nghe có vẻ đúng ("Yêu cầu thanh toán") nhưng trên thực tế, đó là cách Stripe báo cáo các khoản phí không thành công và một số HTTP client và proxy xử lý sai điều này. OpenAI, GitHub, Twilio và Cloudflare đều từ chối các hạn mức vượt quá với 429 và một mã lỗi riêng biệt. Việc làm theo số đông ở đây là bước đi đúng đắn: mọi thư viện retry trên thế giới đều đã biết phải làm gì với các phản hồi của chúng tôi.
Giá trị Retry-After được giới hạn ở mức 24 giờ cho những người thích sleep-and-retry. Nếu bạn muốn thời gian reset thực sự, hãy đọc resets_at từ JSON body.
Băng thông trên trang định giá: Không giới hạn
/prices đã có thêm hàng Băng thông trong ma trận so sánh. Mọi gói công khai đều cung cấp băng thông không giới hạn, và ma trận hiện đã nói rõ điều đó. Đó là thứ bạn không cần cho đến khi khách hàng tiềm năng hỏi và bạn không thể tìm thấy con số. Bây giờ nó đã có trên trang.
Các gói tùy chỉnh có giới hạn băng thông hiển thị con số GB của chúng trên cùng một hàng.
geo-targeting tự chặn bằng một lỗi thích hợp
Nếu một request gửi exitCountries trong khi gói không bao gồm tính năng nhắm mục tiêu theo vị trí địa lý, phản hồi sẽ là 403 với thông báo nêu tên tham số và cách khắc phục. Trước đây, request vẫn được thông qua như thể nhắm mục tiêu theo vị trí địa lý được cho phép. Bây giờ nó thất bại rõ ràng ngay từ đầu.
Các request không có exitCountries không bị ảnh hưởng. Điều này chỉ có tác dụng khi bạn thực sự yêu cầu tính năng này.
Sửa lỗi nhỏ cho Dashboard ở phần Limits và Billing
Ba sửa lỗi về chất lượng trải nghiệm:
- Tab Limits. Tab phụ đã lưu (Overview / API keys / Limits & Features) được khôi phục trước khi vẽ (paint), vì vậy bạn không còn thấy chớp nháy sai tab khi tải lại.
- API Keys. Hộp tìm kiếm sử dụng mẫu tìm kiếm chuẩn thay vì một input trống.
- Billing. Các dòng meta bên dưới Phương thức thanh toán hiện hiển thị với kiểu dáng phù hợp (trước đây chúng bị rớt xuống không có định dạng).
Hậu trường
Các chế độ thực thi giới hạn gói hiện có thể thay đổi trực tiếp (live-flippable). Mỗi một trong sáu giới hạn data-plane (số lượng kết nối đồng thời mỗi sản phẩm, tốc độ mỗi phút, trình duyệt mỗi ngày, tín dụng, băng thông, tính năng) cùng với kiểm tra tạo khóa management-plane có thể được chuyển đổi giữa off, signal và enforce từ một bảng cài đặt mà nhóm của chúng tôi kiểm soát. Không cần redeploy. Một trình làm mới ngầm thăm dò cài đặt mỗi 60 giây và hot path vẫn đồng bộ (synchronous).
Tại sao điều này quan trọng với bạn? Khi một giới hạn hoạt động sai trên production, chúng tôi có thể điều chỉnh lại trong một phút thay vì phải phát hành code mới. Nó cũng cho phép chúng tôi áp dụng thực thi dần dần, cho từng giới hạn, và quan sát xem traffic thực tế diễn ra như thế nào ở mỗi bước. Chế độ signal ghi lại sự kiện mà không block, trong khi enforce sẽ bật phản hồi 429 hoặc 403. Chúng tôi muốn bước trung gian này trở thành một tính năng hoàn chỉnh thay vì chỉ là một công tắc khẩn cấp.
Những con số
Retry-Aftergiới hạn từ chối quota: 24 giờ (thời gian reset thực tế trongresets_at)- Chu kỳ poll cài đặt runtime: 60 giây
- Các gói public không giới hạn băng thông: tất cả
Bộ giới hạn gói đã được triển khai xuyên suốt trong một tháng. Tiếp theo: thực thi các giới hạn đầu tiên (credit và concurrency trên từng sản phẩm có vẻ là cặp đầu tiên phù hợp nhất), cộng với các cảnh báo qua email khi giai đoạn gửi mail được phát hành.