Closed francoisferrand closed 1 year ago
My role is to assist you with the merge of this
pull request. Please type @bert-e help
to get information
on this process, or consult the user documentation.
Status report is not available.
The following approvals are needed before I can proceed with the merge:
the author
2 peers
/approve
The changeset has received all authorizations and has been added to the relevant queue(s). The queue(s) will be merged in the target development branch(es) as soon as builds have passed.
The changeset will be merged in:
development/8.6
The following branches will NOT be impacted:
development/7.10
development/7.4
development/7.70
development/8.4
development/8.5
There is no action required on your side. You will be notified here once the changeset has been merged. In the unlikely event that the changeset fails permanently on the queue, a member of the admin team will contact you to help resolve the matter.
IMPORTANT
Please do not attempt to modify this pull request.
If you need this pull request to be removed from the queue, please contact a member of the admin team now.
The following options are set: approve
I have successfully merged the changeset of this pull request into targetted development branches:
development/8.6
The following branches have NOT changed:
development/7.10
development/7.4
development/7.70
development/8.4
development/8.5
Please check the status of the associated issue BB-402.
Goodbye francoisferrand.
There is a sort of race condition if the
s3:restore
api is used to update the expiration date of the restore object at the last moment, just while it is in-flight: e.g. after it is queued for expiration, but before this queue message gets processed by backbeat.To avoid this, we do an extra check and simply discard the message in that case, relying on cold storage to queue the object for expiration again once it will have reached the "new" expiration date.
Issue: BB-402