Các loại lỗi

Chúng tôi đã phân loại lỗi thành các danh mục chung sau:

  • Xác thực
  • Lỗi có thể thử lại
  • Xác thực
  • Liên quan đến việc đồng bộ hoá

Mặc dù các danh mục này không bao gồm tất cả lỗi có thể xảy ra và một số lỗi có thể thuộc nhiều danh mục, nhưng chúng vẫn có thể đóng vai trò là điểm xuất phát để cấu trúc quy trình xử lý lỗi của ứng dụng. Hãy xem các tài nguyên sau để biết thêm thông tin chi tiết về các lỗi cụ thể:

  • Mục Các lỗi thường gặp cung cấp thêm thông tin chi tiết về một lỗi cụ thể.
  • google.rpc.Status cung cấp thông tin chi tiết về mô hình lỗi logic mà API sử dụng.
  • Mã lỗi chuẩn cung cấp danh sách và nội dung giải thích về mã lỗi chuẩn do gRPC và HTTP xác định trong bối cảnh của Google Ads API.

Lỗi xác thực

Xác thực là việc người dùng đã cấp quyền cho ứng dụng của bạn để truy cập vào Google Ads thay mặt họ hay chưa. Quá trình xác thực được quản lý thông qua thông tin xác thực do quy trình OAuth2 tạo.

Lý do phổ biến nhất khiến lỗi xác thực phát sinh từ các yếu tố nằm ngoài tầm kiểm soát của bạn là người dùng được xác thực đã thu hồi quyền mà họ cấp cho ứng dụng của bạn để thay mặt họ hành động. Ví dụ: nếu ứng dụng của bạn quản lý các tài khoản Google Ads riêng biệt cho khách hàng độc lập và xác thực riêng biệt dưới tư cách của từng khách hàng khi quản lý tài khoản của khách hàng đó, thì khách hàng có thể thu hồi quyền truy cập của ứng dụng bất cứ lúc nào. Tuỳ thuộc vào thời điểm quyền truy cập của bạn bị thu hồi, API có thể trực tiếp trả về lỗi AuthenticationError.OAUTH_TOKEN_REVOKED hoặc các đối tượng thông tin xác thực tích hợp sẵn trong thư viện ứng dụng có thể gửi một ngoại lệ mã thông báo bị thu hồi. Trong cả hai trường hợp, nếu ứng dụng của bạn có giao diện người dùng cho khách hàng, thì ứng dụng có thể yêu cầu họ chạy lại quy trình OAuth2 để thiết lập lại quyền của ứng dụng nhằm thay mặt họ hành động.

Tương tự, nếu dự án trên đám mây của bạn chỉ có Cấp truy cập thử nghiệm và cố gắng gửi yêu cầu đến một tài khoản chính thức (không phải tài khoản thử nghiệm), thì API sẽ trả về một AuthorizationError có giá trị enum phụ thuộc vào phiên bản API:

Lỗi có thể thử lại

Một số lỗi, chẳng hạn như TRANSIENT_ERROR hoặc INTERNAL_ERROR, có thể cho biết một vấn đề tạm thời có thể được giải quyết bằng cách thử lại yêu cầu sau một khoảng thời gian ngắn.

Đối với các yêu cầu do người dùng thực hiện, một chiến lược là ngay lập tức cho biết lỗi trong giao diện người dùng và cung cấp cho người dùng lựa chọn kích hoạt thử lại. Ngoài ra, ứng dụng của bạn có thể tự động thử lại yêu cầu trước, chỉ hiển thị lỗi trong giao diện người dùng sau khi đạt đến số lần thử lại tối đa hoặc tổng thời gian chờ của người dùng.

Đối với các yêu cầu được bắt đầu trên phần phụ trợ, ứng dụng của bạn sẽ tự động thử lại yêu cầu đó cho đến khi đạt số lần thử lại tối đa.

Khi bạn thử lại các yêu cầu, hãy sử dụng chính sách thời gian đợi luỹ thừa với độ trễ ngẫu nhiên. Ví dụ: nếu lần đầu tiên bạn tạm dừng 5 giây trước khi thử lại lần đầu, bạn có thể tạm dừng 10 giây sau lần thử lại thứ hai và 20 giây sau lần thử lại thứ ba, thêm một độ trễ ngẫu nhiên nhỏ vào mỗi khoảng thời gian để ngăn chặn các mức tăng đột biến khi thử lại đồng bộ. Thuật toán thời gian đợi luỹ thừa giúp đảm bảo bạn không gọi API quá nhiều. Nếu lỗi vẫn tiếp diễn sau khi thử lại nhiều lần, hãy ghi lại request-id từ phản hồi để khắc phục sự cố.

Lỗi xác thực

Lỗi xác thực cho biết dữ liệu đầu vào cho một thao tác không được chấp nhận. Ví dụ: PolicyViolationError, DateError, DateRangeError, StringLengthError và UrlFieldError.

Lỗi xác thực thường xảy ra nhất trong các yêu cầu do người dùng thực hiện, khi người dùng nhập dữ liệu đầu vào không hợp lệ. Trong những trường hợp này, bạn nên cung cấp thông báo lỗi thích hợp cho người dùng dựa trên lỗi API cụ thể mà bạn nhận được. Bạn cũng có thể xác thực dữ liệu đầu vào của người dùng để tìm các lỗi thường gặp trước khi thực hiện lệnh gọi API, giúp ứng dụng của bạn phản hồi nhanh hơn và sử dụng API hiệu quả hơn. Đối với các yêu cầu từ phần phụ trợ, ứng dụng của bạn có thể thêm thao tác không thành công vào hàng đợi để người vận hành xem xét.

Nhiều ứng dụng Google Ads duy trì một cơ sở dữ liệu cục bộ để lưu trữ các đối tượng Google Ads. Một thách thức đối với phương pháp này là cơ sở dữ liệu cục bộ có thể không đồng bộ với các đối tượng thực tế trong Google Ads. Ví dụ: người dùng có thể xoá một nhóm quảng cáo ngay trong Google Ads, nhưng ứng dụng và cơ sở dữ liệu cục bộ không biết về thay đổi này và tiếp tục thực hiện lệnh gọi API như thể nhóm quảng cáo đó vẫn tồn tại. Những vấn đề đồng bộ hoá này có thể biểu hiện dưới dạng nhiều lỗi như DUPLICATE_CAMPAIGN_NAME, DUPLICATE_ADGROUP_NAME, AD_NOT_UNDER_ADGROUP, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD và nhiều lỗi khác.

Đối với các yêu cầu do người dùng thực hiện, một chiến lược là cảnh báo người dùng về vấn đề đồng bộ hoá có thể xảy ra, ngay lập tức khởi chạy một công việc truy xuất lớp đối tượng Google Ads có liên quan và cập nhật cơ sở dữ liệu cục bộ, sau đó nhắc người dùng làm mới giao diện người dùng.

Đối với các yêu cầu phụ trợ, một số lỗi cung cấp đủ thông tin để ứng dụng của bạn tự động và dần dần sửa cơ sở dữ liệu cục bộ. Ví dụ: CANNOT_OPERATE_ON_REMOVED_ADGROUPAD sẽ khiến ứng dụng của bạn đánh dấu quảng cáo đó là đã bị xoá trong cơ sở dữ liệu cục bộ. Những lỗi mà bạn không thể xử lý theo cách này có thể khiến ứng dụng của bạn khởi chạy một công việc đồng bộ hoá hoàn chỉnh hơn hoặc được thêm vào hàng đợi để người vận hành xem xét.

Tiếp
Tìm hiểu về lỗi API