Ứng dụng đặt lịch vẫn mở được Google Calendar nhưng một lượt đồng bộ trả về 410. Nhân viên nhìn thấy cuộc hẹn cũ, còn khách đã đổi giờ trên lịch gốc. Vấn đề lúc này nằm ở độ tin cậy của bản sao lịch trong ứng dụng. Bấm thử lại cùng yêu cầu có thể chỉ lặp lại lỗi, trong khi xóa toàn bộ dữ liệu đặt lịch lại tạo một rủi ro lớn hơn.
Bài này dành cho người phụ trách tích hợp lịch hẹn cần xử lý Calendar API syncToken 410. Mục tiêu là khôi phục bản sao sự kiện, giữ dữ liệu nghiệp vụ độc lập và chỉ công bố lịch đã được đối soát. Các tình huống dưới đây là ví dụ thiết kế, không phải số đo hay câu chuyện khách hàng của Onter.
Calendar API syncToken 410 làm mất điều gì?
Token đồng bộ ghi nhận một mốc để lấy các thay đổi tiếp theo. Theo hướng dẫn đồng bộ của Google Calendar, khi mốc này không còn hợp lệ, ứng dụng cần đồng bộ đầy đủ lại. Đây không phải bằng chứng mọi sự kiện trên Google đã bị xóa. Cũng không thể suy từ mã lỗi này rằng mật khẩu người dùng sai.
Điều mất đi là khả năng nối bản sao hiện tại với một chuỗi thay đổi đáng tin cậy. Vì thế, hãy phân biệt ba loại dữ liệu trước khi sửa: sự kiện sao chép từ Calendar; thông tin khách đã nhập vào hệ thống đặt lịch; và liên kết giữa hai bên. Chỉ loại đầu tiên thuộc phạm vi tái dựng bản sao. Phiếu tư vấn, khoản đặt cọc hay ghi chú do nhân viên tạo không nên bị cuốn vào lệnh xóa kho đồng bộ.
Ví dụ giả định: hệ thống có cuộc hẹn nội bộ mã H17, liên kết tới sự kiện E9 trên một lịch cụ thể. Sau sự cố, E9 có thể vẫn tồn tại nhưng đã đổi giờ. Tạo thêm E10 để thay thế ngay sẽ khiến một cuộc hẹn có hai sự kiện. Hướng khôi phục hợp lý là tìm lại E9 trong bản sao mới rồi đối chiếu H17, chưa phát lệnh tạo hoặc hủy lịch từ dữ liệu cũ.
Khoanh đúng lịch và đúng cấu hình truy vấn
Mỗi mốc đồng bộ cần gắn với đúng người dùng, lịch và cấu hình truy vấn. Không dùng một token chung cho các lịch của cả công ty. Nếu đổi cách lấy sự kiện lặp hay phạm vi dữ liệu mà vẫn giữ token cũ, quá trình đối soát sẽ thiếu một định nghĩa ổn định về tập sự kiện đang quản lý.
Lưu một dấu vân tay cấu hình cùng trạng thái đồng bộ là lựa chọn triển khai hữu ích: tên phiên bản tích hợp, lịch đích và các tham số được hỗ trợ. Dấu này phục vụ phát hiện cấu hình lệch, không chứa thông tin xác thực. Khi cấu hình thay đổi có chủ đích, coi đó là một phiên dựng bản sao mới, thay vì cố ghép kết quả của hai cách đọc vào cùng một kho.
Tài liệu events.list nêu rõ những giới hạn của syncToken và phân trang. Trang rỗng chưa chắc là trang cuối. Thiết kế cần đi theo nextPageToken và chỉ nhận nextSyncToken tại cuối lượt. Đừng dùng số lượng sự kiện trả về làm tiêu chí hoàn tất, vì một trang ít dữ liệu vẫn có thể còn trang sau.
Đừng đổi cửa sổ thời gian trong lúc khôi phục
Một màn hình chỉ hiển thị lịch tuần tới không có nghĩa kho đồng bộ cũng chỉ nên lưu tuần tới. Các tham số lọc theo thời gian có giới hạn khi dùng syncToken. Hãy thiết kế riêng lớp dữ liệu đồng bộ hợp lệ và lớp lọc để hiển thị. Nếu hệ thống thực sự dùng mô hình cửa sổ hữu hạn, cần mô tả rõ cách làm mới cửa sổ đó; không gọi một phép truy vấn khác mô hình là tiếp tục chuỗi đồng bộ cũ.
Dựng bản sao mới trước khi thay bản đang dùng
Mẫu an toàn có thể dùng hai thế hệ dữ liệu. Thế hệ A là bản đang phục vụ, nhưng được đánh dấu chưa cập nhật. Thế hệ B nhận kết quả đồng bộ đầy đủ mới. Trong thời gian dựng B, màn hình phải cho biết dữ liệu có thể cũ; các thao tác có hậu quả như xác nhận lịch trống cần kiểm tra lại theo quy tắc nghiệp vụ.
Không bắt buộc mọi hệ thống phải giữ đồng thời hai bản lớn. Với kho nhỏ, có thể tạm dừng phần hiển thị phụ thuộc rồi dựng lại bản sao. Đánh đổi là thời gian gián đoạn. Với lịch phục vụ nhiều nhân viên, hai thế hệ giúp tránh trình bày một tập dữ liệu mới chỉ tải được một nửa như thể đó là danh sách hoàn chỉnh.
Quy trình đề xuất gồm: khóa một tác vụ khôi phục cho đúng lịch; vô hiệu mốc cũ; tạo thế hệ B; đọc lần lượt các trang; ghi sự kiện theo khóa ổn định; rồi lưu mốc mới cùng việc công nhận B hoàn tất. Đây là thiết kế giao dịch phía ứng dụng, không phải tính năng tự động do Calendar thực hiện cho cơ sở dữ liệu của bạn.
Nếu worker dừng ở trang thứ ba, B vẫn chưa được công nhận. Lần chạy tiếp cần biết chính xác trang đã xử lý hoặc bắt đầu lại B theo cơ chế ghi lặp an toàn. Không gắn nhãn thành công chỉ vì lần gọi cuối trước khi dừng trả 200. Thành công của một yêu cầu và tính đầy đủ của cả bản sao là hai bằng chứng khác nhau.
Đối soát cuộc hẹn mà không tự tạo thêm sự kiện
Khóa nhận diện bản sao nên có cả định danh lịch và định danh sự kiện. Tên cuộc hẹn, số điện thoại hoặc giờ bắt đầu không đủ ổn định: người dùng có thể sửa chúng. Với chuỗi lặp, cần giữ đúng mô hình sự kiện mà tích hợp đã chọn, tránh trộn sự kiện gốc và các lần xuất hiện thành những cuộc hẹn độc lập ngoài ý muốn.
Sau khi B đầy đủ, phân các liên kết nội bộ thành ba nhóm để xử lý. Liên kết tìm được sự kiện thì cập nhật trường được phép đồng bộ. Liên kết có trạng thái hủy được xử lý theo quy tắc hủy đã thống nhất. Liên kết chưa tìm được cần đối chiếu phạm vi đọc và quyền trước khi kết luận khách đã hủy. Không dùng một kết quả thiếu do tác vụ lỗi làm bằng chứng xóa hồ sơ.
Ví dụ H17 vẫn có E9, nhưng giờ trên Calendar đã chuyển từ sáng sang chiều. Ứng dụng cần biết trường giờ thuộc nguồn nào. Nếu Google là nguồn quyết định, cập nhật phần lịch và ghi nhận thay đổi; nếu nhân viên phải duyệt việc đổi giờ, đưa vào danh sách đối soát. Bài toán này thuộc quyền sở hữu trường dữ liệu, không thể giải quyết bằng cách chọn bản có thời gian sửa mới hơn một cách máy móc.
Những lịch hẹn đang chờ gửi thông báo cũng cần ranh giới riêng. Không gửi lại email xác nhận cho mọi sự kiện vừa đọc được trong B. Một sự kiện xuất hiện trong lần tái dựng chưa chứng minh đó là cuộc hẹn mới. Tách lịch sử tác vụ gửi thông báo khỏi kho bản sao sẽ giúp khôi phục dữ liệu mà không phát sinh một đợt nhắn tin ngoài ý muốn.
Kiểm thử ba điểm gãy trước khi mở lại
Trước hết, thử một token không hợp lệ trên bộ lịch kiểm thử có quyền sử dụng. Xác nhận chỉ bản sao của lịch đó được dựng lại, hồ sơ nghiệp vụ vẫn còn và tác vụ ghi ngược chưa được mở. Không cần dùng dữ liệu khách thật để chứng minh nhánh lỗi này.
Tiếp theo, ngắt worker giữa các trang. Kiểm tra bản chưa hoàn chỉnh không xuất hiện như lịch chính thức, và việc chạy lại không nhân đôi sự kiện. Cuối cùng, đổi một cuộc hẹn trong lúc đang dựng B rồi chạy lượt đồng bộ tăng dần kế tiếp. Mục đích là xác minh mốc cuối và đường tiếp tục thực sự hoạt động, không chỉ kiểm tra một ảnh chụp dữ liệu tĩnh.
Các lỗi khác phải được phân nhánh riêng. Hướng dẫn xử lý lỗi Calendar API phân biệt lỗi quyền, yêu cầu sai và giới hạn gọi. Một lỗi quyền kéo dài không được sửa bằng xóa bản sao liên tục; một lỗi giới hạn tốc độ cũng không nên kích hoạt hàng loạt phiên tải đầy đủ.
Trong môi trường thử nghiệm, ghi số trang, số sự kiện đã đối soát, thời điểm kết thúc và phiên cấu hình. Tránh đưa mô tả cuộc họp, danh sách người tham dự hoặc token vào log. Nếu cần xem một trường để chẩn đoán, giới hạn quyền và thời gian lưu thay vì xuất nguyên lịch sang tài liệu chia sẻ.
Quy tắc xác định một bản ghi đã xóa cần được thiết kế riêng. Xem thêm đồng bộ tăng dần với bản ghi đã xóa để phân biệt chính sách xóa với việc dựng lại một bản sao bị mất mốc.
Khi nào lịch đủ tin cậy để nhân viên dùng tiếp?
Điều kiện mở lại nên có bằng chứng cụ thể: lượt đọc hoàn tất; mốc mới đã lưu; không còn thế hệ dở được coi là chính thức; liên kết nội bộ đã đối chiếu; các trường thuộc nguồn nào đã rõ; và không có tác vụ gửi thông báo bị phát lại. Số lượng sự kiện bằng nhau chỉ là tín hiệu phụ, bởi một bản thêm nhầm và một bản thiếu có thể bù số lượng cho nhau.
Nếu hệ thống chưa có nơi thử các điểm gãy này, hãy bắt đầu bằng ranh giới môi trường thử nghiệm trước khi cho tác vụ sửa dữ liệu chạy trên lịch đang dùng. Với tích hợp cần nối website đặt lịch, Calendar và hồ sơ tư vấn, Onter có thể hỗ trợ xác định nguồn quyết định, phạm vi phục hồi và tiêu chí nghiệm thu. Nhận tư vấn & báo giá theo luồng thực tế của doanh nghiệp; giá liên hệ.
