Índice
Código
Son los códigos de error canónicos para las APIs de gRPC.
A veces, se pueden aplicar 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; se muestra si la operación tuvo éxito. Asignación HTTP: 200 OK |
CANCELLED |
La operación se canceló (por lo 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 de 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 Asignación HTTP: 400 Solicitud incorrecta |
DEADLINE_EXCEEDED |
El plazo venció antes de que la operación se pudiera completar. Para las operaciones que cambian el estado del sistema, este error puede mostrarse incluso si la operación se completó correctamente. 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 (como un archivo o 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 Asignación HTTP: 404 No encontrado |
ALREADY_EXISTS |
Ya existe la entidad que un cliente intentó crear (como un archivo o directorio). Asignación HTTP: 409 Conflicto |
PERMISSION_DENIED |
El emisor de la llamada no tiene permiso para ejecutar la operación especificada. No se debe usar 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, tal vez 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 Asignación HTTP: 400 Solicitud incorrecta |
ABORTED |
La operación se anuló, generalmente debido a un problema de simultaneidad, como una falla en la verificación del secuenciador o la anulación de la transacción. Para ayudarte a tomar la mejor decisión, lee las descripciones de Asignación HTTP: 409 Conflicto |
OUT_OF_RANGE |
La operación se intentó más allá del rango válido, como buscar o leer más allá del final del archivo. A diferencia de Hay una leve superposición entre 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 espera el sistema subyacente están rotos. 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 volviendo a aplicar una retirada. Ten en cuenta que no siempre es seguro volver a intentar operaciones no idempotentes. Para ayudarte a tomar la mejor decisión, lee las descripciones de Asignación HTTP: 503 Servicio no disponible |
DATA_LOSS |
Daño o pérdida de datos no recuperable. 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 API de REST y las API de RPC. Lo usa gRPC. Cada mensaje Status contiene tres datos: código de error, mensaje de error y detalles del error.
Puedes obtener más información sobre este modelo de error y cómo trabajar con él en la guía de diseño de API.
| Campos | |
|---|---|
code |
El código de estado, que debe ser un valor enum de |
message |
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 |
details[] |
Una lista de mensajes que contienen los detalles del error. Hay un conjunto común de tipos de mensajes para que usen las API. |