OmniDocNếu giao diện báo lỗi, thử lại? Nhiệm vụ tài liệu trước tiên phải phân biệt những lỗi nào có thể được phục hồi
Việc thử lại sau khi báo cáo lỗi là điều rất bình thường. Việc thử lại liên tục sau khi báo cáo lỗi sẽ làm tăng thêm các lỗi nhỏ. Các lỗi về quyền, lỗi tài khoản, tệp bị hỏng và các dịch vụ bận tạm thời sẽ không đi theo cùng một đường dẫn thử lại. Sau khi phân loại, hãy quyết định thời gian chờ đợi, tối đa bao nhiêu lần thử và liệu có cần sự can thiệp của người dùng hay không.
Việc thử lại sau khi một lỗi được báo cáo là một thói quen phổ biến, nhưng nếu bạn thử lại vô thời hạn một cách bừa bãi thì các trục trặc có thể bị phóng đại. Lỗi cấp phép, lỗi tài khoản, tệp bị hỏng và các dịch vụ bận tạm thời phải được xử lý khác nhau.
Bài viết này phù hợp với các nhà phát triển và sinh viên sản phẩm đang thực hiện các tác vụ không đồng bộ như dịch và chuyển đổi tài liệu. Sau khi đọc phần này, trước tiên bạn có thể phân loại các lỗi và sau đó quyết định thời gian chờ đợi, tối đa bao nhiêu lần thử và khi nào cần sự can thiệp của người dùng.
Mã và quy trình bên dưới dựa trên các mẫu tổng hợp đã được thử nghiệm trong môi trường biệt lập. Chúng không đại diện cho sự đảm bảo về tất cả các tài liệu xác thực hoặc tác dụng của sản phẩm. Vui lòng giữ lại bản gốc trước khi xử lý các tài liệu quan trọng và xem xét chúng theo ranh giới và các mục chấp nhận trong văn bản.
Làm cách nào để thử lại sau khi tác vụ tài liệu báo lỗi? Một câu kết luận
Trước tiên, hãy phân loại lỗi trước khi quyết định có nên thử lại hay không: các lỗi tạm thời được giới hạn và rút lại, các vấn đề về quyền và tài khoản bị dừng và bàn giao cho người dùng, còn các lỗi đầu vào sẽ do người dùng khắc phục.
| hoàn cảnh của bạn | Các phương pháp được đề xuất | lý do |
|---|---|---|
| Dịch vụ tắc nghẽn tạm thời | Khoảng lùi có giới hạn, số lần và tổng thời gian chờ có giới hạn | Tránh phát hành lại nhiều lần tất cả các nhiệm vụ cùng một lúc |
| Đăng nhập hoặc quyền không hợp lệ | Nhắc người dùng ủy quyền lại | Việc sử dụng lại thông tin xác thực cũ nhiều lần sẽ chỉ tiếp tục thất bại |
| Tài khoản hoặc hóa đơn bất thường | dừng lại và báo cáo | Không nên tự động nạp tiền hoặc thay đổi tài khoản |
| Lỗi cấu trúc đầu vào | Hãy để người dùng sửa lỗi đầu vào | Không có ích gì khi gửi lại cùng một tập tin |
| Hết thời gian chờ yêu cầu POST | Trước tiên hãy xác nhận xem giao diện có hỗ trợ các khóa bình thường hoặc truy vấn tác vụ hay không. | Nếu máy khách không nhận được phản hồi, điều đó không có nghĩa là máy chủ chưa tạo tác vụ. |
Trước tiên hãy xác định xem việc thử lại có tạo ra các tác vụ trùng lặp hay không.
Thời gian chờ POST đặc biệt rắc rối. Nếu máy khách không nhận được phản hồi, điều đó không có nghĩa là máy chủ chưa tạo tác vụ. Nếu giao diện không có khóa bình thường và không có cơ chế truy vấn tác vụ, việc gửi lại mù có thể tạo ra nhiều tác vụ dịch.
Do đó, chiến lược thử lại trước tiên phải tuân theo hợp đồng giao diện thay vì chỉ nhìn vào mã trạng thái HTTP.
Viết số lần và ngân sách chờ đợi dưới dạng hàm thuần túy
from enum import Enum
class Failure(Enum):
TRANSIENT = "transient"
AUTH = "auth"
BILLING = "billing"
INVALID_INPUT = "invalid_input"
def delay_for(kind, attempt, replay_safe):
if type(attempt) is not int or attempt < 0:
raise ValueError("invalid attempt")
if not replay_safe or kind is not Failure.TRANSIENT:
return None
schedule = (1, 2, 4)
return schedule[attempt] if attempt < len(schedule) else None
assert delay_for(Failure.TRANSIENT, 0, True) == 1
assert delay_for(Failure.TRANSIENT, 2, True) == 4
assert delay_for(Failure.TRANSIENT, 3, True) is None
assert delay_for(Failure.TRANSIENT, 0, False) is None
assert delay_for(Failure.BILLING, 0, True) is None
assert delay_for(Failure.INVALID_INPUT, 0, True) is NoneMã này chỉ tính toán kế hoạch thử lại, không thực sự chờ đợi và không gửi yêu cầu. Một, hai và bốn giây cố định là các giá trị của bản trình diễn tổng hợp và không phải là đề xuất dịch vụ chung.
Môi trường sản xuất cũng cần phải xem xét các điểm sau:
Retry-Afterđược máy chủ trả về- Jitter ngẫu nhiên để tránh tiếp tục một số lượng lớn nhiệm vụ cùng một lúc
- Tổng thời hạn
- Giới hạn số lượng đồng thời
Nếu thời gian chờ mà máy chủ yêu cầu vượt quá ngân sách địa phương thì máy chủ sẽ dừng thử lại thay vì thực hiện yêu cầu trước.
Các loại lỗi tương ứng với các hành động khác nhau
| thất bại | Hành động tùy chọn | không nên được thực hiện theo mặc định |
|---|---|---|
| ùn tắc tạm thời | sơ tán có giới hạn | Tất cả các nhiệm vụ được ban hành lại một cách mạnh mẽ cùng một lúc |
| Đăng nhập hoặc quyền không hợp lệ | Nhắc nhở rõ ràng về việc ủy quyền lại | Tiếp tục lặp lại thông tin xác thực cũ |
| Tài khoản hoặc hóa đơn bất thường | dừng lại và báo cáo | Tự động nạp tiền hoặc thay đổi tài khoản |
| Lỗi cấu trúc đầu vào | Hãy để người dùng sửa lỗi đầu vào | Gửi lại cùng một tập tin |
Lưu các tác vụ logic và bản ghi nỗ lực
Một thao tác của người dùng tương ứng với một nhiệm vụ logic và có thể có nhiều lần thử trong nhiệm vụ logic này. Thời gian bắt đầu, loại lỗi và ID tác vụ từ xa được ghi lại cho mỗi lần thử. Cuối cùng, chỉ có một kết quả được chấp nhận được chọn.
Ưu điểm của việc này là có bản ghi đầy đủ khi khắc phục sự cố retry, đồng thời số lần thử sẽ không bị tính nhầm vào số yêu cầu của người dùng.
📊 So sánh cốt lõi
| ý tưởng | Ghi lại những gì | tác dụng |
|---|---|---|
| Nhiệm vụ logic | thao tác một người dùng | Tương ứng với cùng một yêu cầu mà người dùng nhìn thấy |
| cố gắng ghi lại | Thời gian bắt đầu, loại lỗi, ID tác vụ từ xa | Được sử dụng để khắc phục sự cố trong quá trình thử lại |
| Kết quả nghiệm thu | Một đầu ra đã được chấp nhận | Là kết quả của việc giao hàng cuối cùng |
Sự ổn định của trải nghiệm dịch thuật đến từ lời giải thích rõ ràng
Khi kết nối với OmniDoc, giao diện người dùng phải thông báo rõ ràng cho người dùng trạng thái hiện tại: đang chờ, cần cấp quyền lại hay cần kiểm tra tài khoản. Không hiển thị mọi thứ là "Tòa nhà".
Người dùng sẵn sàng chờ đợi một nhiệm vụ có trạng thái và thoát, nhưng không sẵn sàng nhấp liên tục vào nút mà không có bất kỳ phản hồi nào.
Tham khảo: Python enum.
🎯 Phương pháp nào phù hợp với bạn?
Nếu bạn đang đợi dịch vụ được khôi phục
Sử dụng thời gian chờ có giới hạn, đặt số lần và tổng thời gian chờ tối đa, đồng thời tôn trọngRetry-After của máy chủ.
Nếu bạn có vấn đề về quyền hoặc tài khoản
Dừng việc thử lại tự động và nhắc người dùng ủy quyền lại hoặc kiểm tra trạng thái tài khoản.
Nếu cấu trúc file đầu vào của bạn sai
Hãy để người dùng sửa chữa tập tin trước khi gửi nó. Không gửi lại cùng một tập tin.
Nếu giao diện bạn gọi là POST và có thể hết thời gian chờ
Trước tiên, hãy xác nhận xem giao diện có hỗ trợ khóa bình thường hoặc truy vấn tác vụ hay không, sau đó quyết định có gửi lại hay không.
❓ Câu hỏi thường gặp (FAQ)
1. Có thể thử lại trực tiếp tất cả các lỗi được báo cáo không?
không thể. Lỗi cấp phép, nợ tài khoản, tệp bị hỏng và các dịch vụ bận tạm thời phải được xử lý riêng. Chỉ những thất bại tạm thời mới thích hợp cho việc lùi lại có giới hạn.
2. POST có thể được gửi lại trực tiếp sau khi hết thời gian không?
Không nên gửi lại trực tiếp. Nếu máy khách không nhận được phản hồi, điều đó không có nghĩa là máy chủ chưa tạo tác vụ. Nếu không có cơ chế truy vấn tác vụ hoặc khóa bình thường thì các tác vụ trùng lặp có thể xảy ra.
3. Số lần thử lại và thời gian chờ được xác định như thế nào?
Một, hai và bốn giây cố định chỉ là những minh chứng tổng hợp. Môi trường sản xuất phải được xác định bằng sự kết hợp của Retry-After, jitter ngẫu nhiên, thời hạn tổng thể và giới hạn đồng thời.
4. Số lần thử có ảnh hưởng đến số liệu thống kê về yêu cầu của người dùng không?
Không, chỉ ghi lại thao tác của người dùng dưới dạng tác vụ logic và ghi lại mỗi lần thử lại dưới dạng bản ghi lần thử trong tác vụ.
📝 Tóm tắt
Chìa khóa của việc thử lại không phải là thử nhiều lần mà là phân biệt loại thất bại trước rồi mới quyết định xem phải làm gì. Các lỗi có thể phục hồi sẽ được thử lại trong giới hạn và các sự cố cần xử lý của con người sẽ được trả lại cho người dùng một cách kịp thời.
Thử ngay: Tải tài liệu lên để bắt đầu dịch, giữ nguyên bố cục ban đầu
