Categorizamos los errores en las siguientes categorías generales:
- Autenticación
- Se puede reintentar
- Datos
- Relacionado con la sincronización
Si bien estas categorías no abarcan todos los errores posibles y algunas pueden incluirse en más de una categoría, pueden servir como punto de partida para estructurar el manejo de errores de tu app. Consulta Errores comunes para obtener más detalles sobre un error específico.
Errores de autenticación
La autenticación se refiere a si tu app recibió un permiso del usuario para acceder a Google Ads en su nombre. La autenticación se administra a través de credenciales que genera el flujo de OAuth2.
El motivo más común por el que se produce un error de autenticación por factores que escapan a tu control es que el usuario autenticado revocó el permiso que le dio a tu app para actuar en su nombre. Por ejemplo, si tu app administra cuentas de Google Ads separadas para clientes independientes y se autentica por separado como cada cliente cuando administra la cuenta de ese cliente, un cliente podría revocar el acceso de tu app en cualquier momento. Según cuándo se haya revocado el acceso, la API puede mostrar directamente un error AuthenticationError.OAUTH_TOKEN_REVOKED o los objetos de credenciales integradas en las bibliotecas cliente pueden generar una excepción revocada de token. En cualquier caso, si la app tiene una IU para tus clientes, podría pedirles que reinicien el flujo de OAuth2 a fin de restablecer el permiso de tu app para actuar en su nombre.
Errores que se pueden volver a intentar
Algunos errores, como TRANSIENT_ERROR o INTERNAL_ERROR, pueden indicar un problema temporal que se puede resolver reintentando la solicitud después de una pausa breve.
Para las solicitudes iniciadas por el usuario, una estrategia es indicar de inmediato un error en tu IU y darle la opción de activar un reintento. Como alternativa, tu app primero podría reintentar la solicitud automáticamente y solo exponer el error en la IU después de alcanzar una cantidad máxima de reintentos o el tiempo de espera total del usuario.
En el caso de las solicitudes iniciadas en el backend, tu app debe reintentar la solicitud automáticamente hasta una cantidad máxima de reintentos.
Cuando reintentes las solicitudes, usa una política de retirada exponencial. Por ejemplo, si primero pausas 5 segundos antes del primer reintento, puedes pausar 10 segundos después del segundo y 20 segundos después del tercer reintento. La retirada exponencial ayuda a garantizar que no llames a la API demasiado agresivamente.
Errores de validación
Los errores de validación indican que no se aceptó una entrada para una operación.
Por ejemplo, PolicyViolationError, DateError, DateRangeError, StringLengthError y UrlFieldError.
Los errores de validación ocurren con mayor frecuencia en las solicitudes iniciadas por el usuario, en las que este ingresó una entrada no válida. En estos casos, debes proporcionar un mensaje de error adecuado al usuario según el error específico de la API que recibiste. También puedes validar la entrada del usuario para errores comunes antes de realizar una llamada a la API, lo que hace que tu app tenga una mayor capacidad de respuesta y el uso de la API sea más eficiente. Para las solicitudes del backend, tu app podría agregar la operación con errores a una cola para que un operador humano la revise.
Errores relacionados con la sincronización
Muchas aplicaciones de Google Ads mantienen una base de datos local para almacenar sus objetos de Google Ads. Uno de los desafíos de este enfoque es que la base de datos local puede no estar sincronizada con los objetos reales en Google Ads. Por ejemplo, un usuario puede borrar un grupo de anuncios directamente en Google Ads, pero la aplicación y la base de datos local no están al tanto del cambio y siguen emitiendo llamadas a la API como si el grupo de anuncios existiera. Estos problemas de sincronización se pueden manifestar como una variedad de errores, como DUPLICATE_CAMPAIGN_NAME, DUPLICATE_ADGROUP_NAME, AD_NOT_UNDER_ADGROUP, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD, entre otros.
Para las solicitudes iniciadas por el usuario, una estrategia es alertar al usuario sobre un posible problema de sincronización, iniciar de inmediato una tarea que recupere la clase relevante de objetos de Google Ads y actualice la base de datos local y, luego, solicitarle al usuario que actualice la IU.
En el caso de las solicitudes de backend, algunos errores proporcionan suficiente información para que tu app corrija de forma automática e incremental tu base de datos local. Por ejemplo, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD debería hacer que tu app marque ese anuncio como quitado de tu base de datos local. Los errores que no puedes solucionar de esta manera podrían hacer que tu app inicie un trabajo de sincronización más completo o se agregue a una cola para que un operador humano lo revise.