Troubleshoot common issues
Stay organized with collections
Save and categorize content based on your preferences.
Check the following sections for help if you experience any issues.
Lost state in Fleet Engine
When working with Fleet Engine, design your implementation to anticipate
failures. For example, if you issue a request to Fleet Engine to update a
vehicle, it might respond with an error indicating that the vehicle does not
exist. Your implementation should then recreate the vehicle in the new state.
In the extremely unlikely scenario of a catastrophic failure of Fleet Engine,
you may need to recreate most or all vehicles and tasks. If the creation rate
becomes too high, some requests may fail again due to quota issues since quota
checks are in place to avoid denial of service (DOS) attacks. In this case, slow
down the recreation rate using a backoff strategy for reattempts.
Retries
Be sure your system implements retries for requests to Fleet Engine since they
might fail occasionally. Fleet Engine client libraries issue retries by default.
Lost state in the driver app
If the driver app crashes, the app must recreate the current state within the
Driver SDK. The app should attempt to recreate tasks to ensure that they exist
and to restore their current states. The app should also recreate and explicitly
set the list of stops for the Driver SDK.
Note: These restorations must be done autonomously without relying on
information from Fleet Engine, other than errors indicating if and when an
entity already exists in the database. If an entity does already exist, then
that error can be absorbed and the entity can be updated using its ID.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-02-24 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-02-24 UTC."],[[["Fleet Engine implementations should be designed to handle failures and potential data loss by recreating vehicles and tasks when necessary."],["In case of Fleet Engine failures, use a backoff strategy to manage the recreation rate and avoid quota issues."],["Implement retries for Fleet Engine requests to address occasional failures, leveraging client library defaults or custom mechanisms."],["Driver apps should autonomously restore state after crashes by recreating tasks and stops within the Driver SDK, relying on error handling for existing entities."]]],["Implement error handling for Fleet Engine failures, such as vehicle non-existence, by recreating entities. In catastrophic failures, recreate vehicles and tasks, using a backoff strategy if quota issues arise. Implement request retries, as provided by Fleet Engine client libraries. If the driver app crashes, autonomously recreate tasks and stop lists within the Driver SDK, relying only on Fleet Engine errors to determine if entities already exist for update purposes.\n"]]
