Lần gửi đã hết thời gian đó có thực sự lưu công việc của bạn không?

Nút xoay, thẻ hiện lỗi, và biểu mẫu bạn dành mười phút điền đã biến mất. Điều bạn không biết là thao tác ghi có đến nơi trước khi kết nối chết hay không. Coi sự không rõ đó là thất bại chính là cách sinh ra bình luận trùng, đơn hàng đôi và phiếu hỗ trợ lặp lại.

Khôi phục theo một thứ tự cố định: giữ văn bản, tìm kết quả, và chỉ sau đó mới quyết định xem lần gửi thứ hai có được phép không.

Bắt đầu từ văn bản và dấu thời gian

Sao chép nội dung khỏi trang trước khi chạm vào bất cứ thứ gì khác, kể cả bản nháp mà trình duyệt vẫn giữ trong ô. Ghi lại giờ, trang bạn đang ở và hành động bạn đã làm, vì chính ba chi tiết đó mới khiến phần còn lại của cuộc điều tra khả thi. Nếu thẻ vẫn mở, hãy để nó mở cho đến khi bạn đọc mục mạng. Lưu văn bản không tốn gì, còn mất nó tốn cả công việc.

Sau đó tách hai dạng lỗi mà bạn thực sự có thể quan sát. Kết nối đứt giữa chừng và máy chủ trả lời bằng lỗi trông khác nhau trong bảng mạng, và chỉ dạng thứ hai cho bạn biết điều gì đó về quyết định của ứng dụng.

Tìm kết quả trong chính chế độ xem của ứng dụng

Tải lại chế độ xem đọc sẽ hiển thị kết quả: danh sách bình luận, lịch sử đơn hàng, hàng đợi phiếu hỗ trợ hoặc bản ghi bạn đang sửa. Đối chiếu theo tài khoản, điểm đến, thời gian và nội dung thay vì theo mục mới nhất, vì người khác có thể đã viết sau bạn. Với tác vụ nền, hãy tra cứu tham chiếu sẵn có và trạng thái của nó thay vì tạo một thao tác mới làm phép thử kết nối.

Nếu kết quả ở đó, bạn xong việc và lỗi thuộc về đường phản hồi chứ không phải đường ghi. Nếu không có, hãy giữ khả năng ứng dụng chưa xác nhận: một tác vụ trong hàng đợi, một chế độ xem đọc bị trễ hoặc một bản sao chạy sau có thể che giấu một thao tác ghi thành công trong một lúc.

Hãy cho nó một lần xem thứ hai đã định trước khi kết luận, và ghi lại thời điểm của cả hai lần kiểm tra. Hai lần kiểm tra cách nhau hai mươi giây là bằng chứng yếu hơn nhiều so với hai lần cách nhau mười phút.

Quyết định xem lần gửi thứ hai có an toàn không

Câu trả lời phụ thuộc vào thao tác, không phụ thuộc vào sự kiên nhẫn của bạn. HTTP phân biệt các phương thức có thể lặp lại với cùng hiệu ứng dự định với những phương thức không thể, và khuyên không tự động thử lại loại thứ hai trừ khi biết rằng ngữ nghĩa cho phép. Tạo bình luận, đặt hàng và gửi thanh toán thường thuộc nhóm thứ hai, vì thế một cú nhấp thứ hai có vẻ thành công không nói gì về lần đầu.

Nếu bạn bảo trì máy khách, hãy dùng cơ chế thử lại hoặc idempotency mà API ghi trong tài liệu, và gắn nó với cùng một thao tác logic thay vì tạo khóa mới cho mỗi lần thử. Mã định danh yêu cầu dùng để truy vết không phải khóa chặn trùng lặp trừ khi máy chủ coi nó như vậy.

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

Khóa chỉ hữu ích nếu dịch vụ lưu nó gắn với thao tác và trả lại kết quả ban đầu khi lặp lại. Hãy thử hành vi đó trên một điểm cuối thử nghiệm trước khi dựa vào nó trong môi trường thật.

Thu thập bằng chứng trước khi nhấn bất cứ thứ gì lần nữa

Giữ mục mạng thay vì ảnh chụp màn hình lỗi. Phương thức yêu cầu, URL, phản hồi hoặc thời gian chờ và thời điểm xảy ra là những gì quản trị viên có thể đối chiếu với hồ sơ của ứng dụng. Chỉ xuất hoặc sao chép mục đó dưới dạng lệnh nếu sau đó bạn gỡ cookie, tiêu đề ủy quyền và mọi nội dung riêng tư khỏi bản sao. Hãy để phiên của bạn nguyên vẹn, và đừng bao giờ phát lại một yêu cầu bị bắt giữ có thông tin đăng nhập như một lối tắt.

Hỏi chủ dịch vụ một câu cụ thể: thao tác với nội dung này vào thời điểm này có thành công không, và có tham chiếu cho nó không? Câu hỏi đó có câu trả lời, còn "trang web có hỏng không" thì không.

Mục đích của bài tập là xác lập rằng hành động đã xảy ra đúng một lần. Một thông báo lỗi bạn có thể đóng không giống một bản ghi bạn có thể tin, và cái thứ hai là thứ bạn cần trước khi gửi bất cứ điều gì khác.