CLDSRV-956: accept RestoreObject during the direct-to-cold archive window - #6291
Merged
Merged
Conversation
Contributor
Hello francoisferrand,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
An object written directly to a cold location is declared cold as soon as the PUT returns, but its data stays hot until the queue populator drives the transition. Nothing lets a client see that window, so it may legitimately ask for a restore, which was rejected since the object is not in a cold location yet. Such a restore is now accepted and simply recorded in the archive metadata, without any archive info: there is nothing to recall yet, so backbeat initiates it once the archive completes. The client gets the usual 202 and ongoing-request="true", indistinguishable from a slow cold backend, and a repeated request updates the pending one instead of failing as already in progress. The object is still physically hot in that state, so reading it keeps working: the availability check now keys on the archive info rather than on the mere presence of an archive block, which is also how the queue populator tells a direct-to-cold object from a restored one. Restoring it does not reserve any hot space either, as it is already accounted for. Creating such objects remains gated by enableDirectToCold, but restoring one which already exists is not, so that turning the flag off does not strand objects behind. Issue: CLDSRV-956
francoisferrand
force-pushed
the
improvement/CLDSRV-956
branch
from
September 11, 2026 16:22
782adb3 to
f50ea3f
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
@@ Coverage Diff @@
## development/9.5 #6291 +/- ##
===================================================
+ Coverage 86.54% 86.56% +0.01%
===================================================
Files 213 213
Lines 14615 14621 +6
===================================================
+ Hits 12649 12657 +8
+ Misses 1966 1964 -2
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
The prettier CI check runs on the files touched by a PR, so the ones this change touches now need to comply. Issue: CLDSRV-956
Contributor
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
delthas
approved these changes
Sep 14, 2026
benzekrimaha
approved these changes
Sep 15, 2026
Contributor
Author
|
/approve |
Contributor
|
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
This pull request did not target the following hotfix branch(es) so they
Please check the status of the associated issue CLDSRV-956. Goodbye francoisferrand. The following options are set: approve |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An object written directly to a cold location (CLDSRV-917) is declared cold as soon as the PUT returns, but its data stays in the hot location until the lifecycle queue populator drives the transition. Nothing lets a client see that window — it looks like a regular cold object — so a conforming application may legitimately issue a
RestoreObject, which we rejected withInvalidObjectStatesince the object is not in a cold location yet.Such a restore is now accepted and recorded in the
archiveblock (restoreRequestedAt,restoreRequestedDays), without anyarchiveInfo: there is nothing to recall yet, so backbeat initiates it once the archive completes (BB-804). The client gets the usual 202 andongoing-request="true", indistinguishable from a slow cold backend, and a repeated request updates the pending one rather than failing as already in progress.Keying on
archiveInforather than on the presence of thearchiveblock matters in two places: the object stays readable while its data is still hot, and the queue populator uses the same signal to tell a direct-to-cold object from a restored one — so recording a restore does not stop it from being picked up for transition.Creating such objects remains gated by
enableDirectToCold. Restoring one that already exists is not, so turning the flag off does not strand objects behind.Note on quotas: a deferred restore is charged against hot space like any other, so the object is briefly counted twice during the archive window, until the GC removes the hot copy on archive completion. That is deliberate — the deferred restore is later initiated by the queue populator, which never goes through the quota path, so skipping the charge here would leave the restored copy unaccounted for.
HeadObjectneeded no change: it already reports the cold storage class, the transition flag andx-amz-restore. Tests now pin that.The second commit keeps the cold condition in
verifyColdObjectAvailableuntouched and only adds an early return for objects with no archive info. Collapsing it into a single!restoreCompletedAttest, as the first commit did, also made an archived object with a completed restore but no restore request readable — the wrong direction for data sitting in a cold backend.Issue: CLDSRV-956