Re: Backport OAK-7998 to 1.10.3
Ah yes, I think that was a typo. Thanks Julian. On Thu, Jul 18, 2019 at 2:14 AM Julian Reschke wrote: > On 18.07.2019 02:06, Matt Ryan wrote: > > 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 > > +1, but note that 1.10.3 was released last week. So it would be > something for 1.10.4... > > Best regards, Julian > >
Re: Backport OAK-7998 to 1.10.3
On 18.07.2019 02:06, Matt Ryan wrote: 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 +1, but note that 1.10.3 was released last week. So it would be something for 1.10.4... Best regards, Julian
Backport OAK-7998 to 1.10.3
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
