Hi, I propose to backport the fix for OAK-7998 to 1.10.3.
The issue in OAK-7998 is that it is possible to obtain a direct download URI for a binary that doesn't exist in blob storage. While not usually possible, this situation can arise if the binary in question was added via addRecord() and then a download URI is immediately requested, if the binary is in cache and is not yet uploaded to cloud storage. In such a case the binary is "in the repo" but we can't create a valid download URI for it until it is actually in cloud storage. The fix is implemented for 1.16. It is a low-risk change - a couple of unit test changes and an additional check to see whether the blob ID exists in both the S3 and Azure backend implementations. -MR
