Consultez les sections suivantes pour obtenir de l'aide en cas de problème.
Perte d'état dans Fleet Engine
Lorsque vous utilisez Fleet Engine, concevez votre implémentation de manière à anticiper les échecs. Par exemple, si vous envoyez une requête à Fleet Engine pour mettre à jour un véhicule, il peut répondre par une erreur indiquant que le véhicule n'existe pas. Votre implémentation doit alors recréer le véhicule dans le nouvel état.
Dans le scénario extrêmement improbable d'une défaillance catastrophique de Fleet Engine, vous devrez peut-être recréer la plupart ou la totalité des véhicules et des tâches. Si le taux de création devient trop élevé, certaines requêtes peuvent échouer à nouveau en raison de problèmes de quota, car des vérifications de quota sont en place pour éviter les attaques par déni de service (DoS). Dans ce cas, ralentissez le taux de recréation à l'aide d'une stratégie d'intervalle entre les tentatives.
Tentatives
Assurez-vous que votre système implémente des tentatives pour les requêtes adressées à Fleet Engine, car elles peuvent parfois échouer. Les bibliothèques clientes Fleet Engine émettent des tentatives par défaut.
Perte d'état dans l'application chauffeur
Si l'application chauffeur plante, elle doit recréer l'état actuel dans le Driver SDK. L'application doit tenter de recréer des tâches pour s'assurer qu'elles existent et pour restaurer leur état actuel. L'application doit également recréer et définir explicitement la liste des arrêts pour le Driver SDK.
Remarque : Ces restaurations doivent être effectuées de manière autonome, sans s'appuyer sur des informations provenant de Fleet Engine, autres que les erreurs indiquant si et quand une entité existe déjà dans la base de données. Si une entité existe déjà, cette erreur peut être absorbée et l'entité peut être mise à jour à l'aide de son ID.
Erreurs de dépassement de délai
Si vous recevez une erreur DEADLINE_EXCEEDED lorsque vous appelez Fleet Engine, la requête a pris plus de temps que le délai d'inactivité configuré. Les bibliothèques clientes Fleet Engine ont des délais d'inactivité par défaut, mais vous devrez peut-être les ajuster.
Pour obtenir des informations générales sur les délais d'inactivité gRPC, consultez gRPC et délais d'inactivité.
Pour configurer le délai d'inactivité lorsque vous utilisez la bibliothèque cliente Java Fleet Engine, vous pouvez ajuster les paramètres de nouvelle tentative RPC. L'exemple suivant montre comment configurer un délai d'inactivité personnalisé lors de la configuration de VehicleService :
VehicleServiceSettings.Builder settingsBuilder = VehicleServiceSettings.newBuilder();
// Set the timeout to 10 seconds.
settingsBuilder
.getVehicleSettings()
.setRetrySettings(
settingsBuilder.getVehicleSettings().getRetrySettings().toBuilder()
.setTotalTimeout(java.time.Duration.ofSeconds(10))
.build());
VehicleServiceClient client = VehicleServiceClient.create(settingsBuilder.build());
Erreurs d'API courantes
Cette section répertorie les erreurs d'API courantes que vous pouvez rencontrer, leurs causes et comment les résoudre.
NOT_FOUND (HTTP 404)
L'entité demandée (comme un véhicule, un trajet ou une tâche) n'a pas pu être trouvée.
- Cause : généralement due à une tentative d'obtention, de mise à jour ou de suppression d'une entité à l'aide d'un ID qui n'existe pas dans la base de données.
- Correction : vérifiez que l'ID de l'entité est correct et que l'entité a été créée avant de tenter d'y accéder.
ALREADY_EXISTS (HTTP 409)
L'entité que vous essayez de créer existe déjà.
- Cause : due à l'appel d'une méthode de création (comme
CreateVehicleouCreateTrip) avec un ID déjà utilisé. - Correction : mettez à jour l'entité existante ou utilisez un nouvel ID unique pour la requête de création.
PERMISSION_DENIED (HTTP 403)
Vous ne disposez pas des autorisations nécessaires pour effectuer la requête.
- Cause : cela se produit généralement si votre jeton Web JSON (JWT) ne contient pas les revendications appropriées ou si le compte de service qui signe le JWT ne dispose pas des rôles IAM requis. Par exemple, "Le JWT ne contient pas de champ d'application correspondant pour le trajet demandé."
- Correction : vérifiez les autorisations de votre compte de service et assurez-vous que vos revendications JWT incluent les champs d'application appropriés pour l'entité à laquelle vous essayez d'accéder.
INVALID_ARGUMENT (HTTP 400)
Un ou plusieurs arguments transmis dans la requête ne sont pas valides.
- Cause : cela peut se produire pour diverses raisons, par exemple si vous fournissez une
valeur hors plage (par exemple, une capacité maximale), si vous omettez un champ obligatoire (par exemple, un
VehicleType) ou si vous fournissez des coordonnées non valides pour un point de prise en charge. - Correction : consultez le message d'erreur pour le champ spécifique qui n'est pas valide et assurez-vous que votre requête est conforme à la spécification de l'API.
FAILED_PRECONDITION (HTTP 400)
L'opération a été rejetée, car le système n'est pas dans un état requis pour son exécution.
- Cause : les causes courantes incluent la tentative de modification d'un trajet
COMPLETEouCANCELEDvers un autre état, ou la tentative d'attribution d'une tâcheCLOSEDà un véhicule. - Correction : assurez-vous que l'état actuel de l'entité autorise l'opération que vous tentez d'effectuer. Consultez le message d'erreur pour connaître les violations d'état spécifiques.
UNAVAILABLE (HTTP 503)
Le service est indisponible.
- Cause : cela indique un problème temporaire avec le service Fleet Engine.
- Correction : la requête peut être relancée en toute sécurité avec un intervalle exponentiel entre les tentatives.