Package google.rpc

Índice

• Code (enum)
• Status (mensaje)

Código

Son los códigos de error canónicos para las APIs de gRPC.

A veces, es posible que se apliquen varios códigos de error. Los servicios deben devolver el código de error más específico que corresponda. Por ejemplo, se prefiere OUT_OF_RANGE por sobre FAILED_PRECONDITION, si se aplican ambos códigos. Del mismo modo, se prefiere NOT_FOUND o ALREADY_EXISTS por sobre FAILED_PRECONDITION.

Enums
OK	No es un error, que se muestra con éxito. Asignación HTTP: 200 OK
CANCELLED	La operación se canceló (en general, la cancela el emisor). Asignación HTTP: 499 Solicitud cerrada por el cliente
UNKNOWN	Error desconocido. Por ejemplo, este error puede mostrarse cuando un valor Status recibido de otro espacio de direcciones pertenece a un espacio de error desconocido en este espacio de direcciones. Además, los errores que las APIs generan y que no muestran suficiente información pueden convertirse en este error. Asignación HTTP: 500 Error interno del servidor
INVALID_ARGUMENT	El cliente especificó un argumento no válido. Ten en cuenta que esto difiere de FAILED_PRECONDITION. INVALID_ARGUMENT indica los argumentos que son problemáticos sin importar el estado del sistema (p. ej., un nombre de archivo con formato incorrecto). Asignación HTTP: 400 Solicitud incorrecta
DEADLINE_EXCEEDED	El plazo venció antes de que la operación se pudiera completar. En el caso de las operaciones que cambian el estado del sistema, es probable que se muestre este error incluso si la operación se completó con éxito. Por ejemplo, una respuesta correcta desde un servidor podría haberse demorado lo suficiente como para que el plazo venciera. Asignación HTTP: 504 Tiempo de espera de la puerta de enlace
NOT_FOUND	No se encontró alguna entidad solicitada (p. ej., un archivo o un directorio). Nota para los desarrolladores de servidores: Si se niega una solicitud a una clase completa de usuarios, como el lanzamiento gradual de funciones o una lista de entidades permitidas no documentada, se puede usar NOT_FOUND. Si se niega una solicitud a algunos usuarios de una clase, como el control de acceso basado en usuarios, se debe usar PERMISSION_DENIED. Asignación HTTP: 404 No encontrado
ALREADY_EXISTS	La entidad que un cliente intentó crear (p. ej., un archivo o un directorio) ya existe. Asignación HTTP: 409 Conflicto
PERMISSION_DENIED	El emisor no tiene permiso para ejecutar la operación especificada. No se debe usar PERMISSION_DENIED en los rechazos por agotamiento de algún recurso (en su lugar, se debe usar RESOURCE_EXHAUSTED). No se debe usar PERMISSION_DENIED si no se puede identificar al emisor (en su lugar, se debe usar UNAUTHENTICATED). Este código de error no sugiere que la solicitud sea válida ni que la entidad solicitada exista o satisfaga otras condiciones previas. Asignación HTTP: 403 Prohibido
UNAUTHENTICATED	La solicitud no tiene credenciales de autenticación válidas para la operación. Asignación HTTP: 401 No autorizado
RESOURCE_EXHAUSTED	Algunos recursos se agotaron, quizás una cuota por usuario, o tal vez se agotó el espacio de todo el sistema de archivos. Asignación HTTP: 429 Demasiadas solicitudes
FAILED_PRECONDITION	La operación se rechazó debido a que el sistema no se encuentra en un estado necesario para la ejecución de la operación. Por ejemplo, el directorio que se borrará no está vacío o se aplicará una operación rmdir a un archivo que no es de directorio, entre otros. Los implementadores de servicios pueden usar los siguientes lineamientos para decidir entre FAILED_PRECONDITION, ABORTED y UNAVAILABLE: (a) Usa UNAVAILABLE si el cliente puede reintentar solo la llamada con errores. (b) Usa ABORTED si el cliente debe reintentar en un nivel superior (p.ej., cuando falla una prueba y un conjunto especificado por el cliente, lo que indica que el cliente debe reiniciar una secuencia de lectura, modificación y escritura). (c) Usa FAILED_PRECONDITION si el cliente no debe volver a intentar hasta que el estado del sistema se haya corregido de forma explícita. Por ejemplo, si un "rmdir" falla porque el directorio no está vacío, se debe mostrar FAILED_PRECONDITION, ya que el cliente no debe reintentar, a menos que se borren los archivos del directorio. Asignación HTTP: 400 Solicitud incorrecta
ABORTED	La operación se anuló. Esto suele ocurrir debido a un problema de simultaneidad, como una falla en la verificación del secuenciador o la anulación de la transacción. Consulta los lineamientos anteriores para optar por FAILED_PRECONDITION, ABORTED o UNAVAILABLE. Asignación HTTP: 409 Conflicto
OUT_OF_RANGE	Se intentó realizar la operación fuera del rango válido. P. ej., buscar o leer el final del archivo. A diferencia de INVALID_ARGUMENT, este error indica un problema que se puede solucionar si el estado del sistema cambia. Por ejemplo, un sistema de archivos de 32 bits generará INVALID_ARGUMENT si se le pide que lea en un desplazamiento que no esté en el rango [0,2^32-1], pero generará OUT_OF_RANGE si se le solicita que lea desde un desplazamiento superior al tamaño del archivo actual. Hay una leve superposición entre FAILED_PRECONDITION y OUT_OF_RANGE. Recomendamos usar OUT_OF_RANGE (el error más específico) cuando sea necesario, de modo que los emisores que iteran por medio de un espacio puedan buscar de forma sencilla un error OUT_OF_RANGE y, de esta manera, detectar cuando finalicen. Asignación HTTP: 400 Solicitud incorrecta
UNIMPLEMENTED	La operación no se implementó, no se admite o no está habilitada en este servicio. Asignación HTTP: 501 No implementado
INTERNAL	Errores internos. Esto significa que algunos invariantes que el sistema subyacente espera están dañados. Este código de error está reservado para errores graves. Asignación HTTP: 500 Error interno del servidor
UNAVAILABLE	El servicio no está disponible por el momento. Lo más probable es que esta sea una condición transitoria y que se pueda corregir si vuelves a intentar una retirada. Consulta los lineamientos anteriores para decidir entre FAILED_PRECONDITION, ABORTED y UNAVAILABLE. Asignación HTTP: 503 Servicio no disponible
DATA_LOSS	Daño o pérdida de datos irrecuperable. Asignación HTTP: Error interno del servidor 500

Estado

El tipo de Status define un modelo de error lógico que es adecuado para entornos de programación diferentes, incluidas las APIs de REST y las APIs de RPC. Lo usa gRPC. El modelo de errores está diseñado para ser de la siguiente forma:

• Fácil de usar y entender para la mayoría de los usuarios
• Lo suficientemente flexible para satisfacer necesidades inesperadas

Resumen

El mensaje Status contiene tres datos: código de error, mensaje de error y detalles del error. El código de error debe ser un valor de enumeración de google.rpc.Code, pero puede aceptar códigos de error adicionales si es necesario. El mensaje de error debe ser un mensaje en inglés dirigido al desarrollador que ayude a los desarrolladores a entender y resolver el error. Si se necesita un mensaje de error localizado orientado al usuario, coloca el mensaje localizado en los detalles del error o localízalo en el cliente. Los detalles opcionales del error pueden contener información arbitraria sobre el error. Hay un conjunto predefinido de tipos de detalles del error en el paquete google.rpc que puede usarse para condiciones de error comunes.

Asignación de idiomas

El mensaje Status es la representación lógica del modelo de errores, pero no es necesariamente el formato de conexión real. Cuando el mensaje Status se expone en diferentes bibliotecas cliente y diferentes protocolos de conexión, puede asignarse de manera diferente. Por ejemplo, probablemente se asignará a algunas excepciones en Java, pero es más probable que se asigne a algunos códigos de error en C.

Otros usos

El modelo de error y el mensaje Status pueden usarse en una variedad de entornos, con o sin API, para proporcionar una experiencia de desarrollador consistente en diferentes entornos.

Los ejemplos de usos de este modelo de error incluyen lo siguiente:

• Errores parciales. Si el servicio debe mostrar errores parciales al cliente, puede incorporar Status en la respuesta normal para indicar los errores parciales.

• Errores de flujo de trabajo. Un flujo de trabajo típico tiene varios pasos. Cada paso puede tener un mensaje Status para los informes de errores.

• Operaciones por lotes. Si un cliente usa una solicitud por lotes y una respuesta por lotes, el mensaje Status debe usarse directamente dentro de la respuesta por lotes y debe haber uno para cada respuesta secundaria de error.

• Operaciones asíncronas. Si una llamada a la API incorpora los resultados de la operación asíncrona en su respuesta, el estado de esas operaciones debe representarse directamente mediante el uso del mensaje Status.

• Si algunos errores de la API se almacenan en los registros, el mensaje Status podría usarse directamente después de cualquier eliminación necesaria por razones de seguridad o privacidad.

Campos
code	int32 El código de estado, que debe ser un valor enum de google.rpc.Code.
message	string Un mensaje de error dirigido al desarrollador, que debe estar en inglés. Cualquier mensaje de error dirigido al usuario debe localizarse y enviarse al campo google.rpc.Status.details; o el cliente debe localizarlo.
details[]	Any Una lista de mensajes que contienen los detalles del error. Hay un conjunto común de tipos de mensajes para que usen las API.