ProcessCarImage is Not Idempotent

[NullPointer4096]

Description:
The ProcessCarImage function is invoked when a new image appears in the blob storage. The function aims to send a license plate read message to Service Bus. It first invokes the plate recognition service, copies the image blob to an archive folder, and deletes the original blob. If the plate recognition result has a "low" quality, the function invokes a durable orchestrator to wait for human approval for further processing. However, if the function runtime crashes after deleting the original image but before sending the message to Service Bus, when the function is retried, no image will be found for the workflow. Function runtime crashes can occur due to a variety of reasons. Some common causes include: software, hardware, and, network timeout.

Issue:
The ProcessCarImage function does not ensure idempotency when the function runtime untimely crashes after deleting the image but before the function successfully finishes. This may result in the Service Bus message never being sent, even when the function is retried.

Suggested fix:
Adjust the steps of the workflow to make the workflow idempotent:

1. (a) If the original blob exists, invoke the recognition service using the original image. (b) Otherwise, use the archived blob as the input of the service.
2. Archive the blob if the original blob exists.
3. Delete the blob if it exists (use imageBlob.DeleteIfExistsAsync() instead of imageBlob.DeleteAsync()).
4. Invoke an orchestrator if the read quality is low.
5. Send the plate info to Service Bus.

By following this adjusted workflow, we can ensure idempotency and prevent the issue of Service Bus messages not being sent due to function runtime crashes. If a crash happens before step 3, the retry will follow the same steps from 1(a). If a crash happens after step 3 (so the original blob has been deleted), when the function retries, the source of the image will be the previously archived blob (i.e., the workflow starts from 1(b)).