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.