Repository navigation
Do not delete data on a CRR location when backbeat updates metadata - #6328
SylvainSenechal wants to merge 1 commit into
Conversation
Hello sylvainsenechal,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command: Alternatively, the |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
... and 3 files with indirect coverage changes @@ Coverage Diff @@
## development/9.5 #6328 +/- ##
===================================================
- Coverage 87.89% 87.82% -0.08%
===================================================
Files 206 206
Lines 14193 14193
===================================================
- Hits 12475 12465 -10
- Misses 1718 1728 +10
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
| // also be from an empty object. | ||
| (omVal['content-length'] === 0 || (omVal.location && Array.isArray(omVal.location))) && | ||
| locationKeysHaveChanged(objMd.location, omVal.location) | ||
| locationKeysHaveChanged(objMd.location, omVal.location) && |
There was a problem hiding this comment.
Issue: CLDSRV-1034
When backbeat updates an object's metadata with the cloudserver’s backbeat api, cloudserver deletes the object's old data locations if they changed.
With pull replication, the sink copies an object's data from a remote CRR location (the source site) to a local one, then updates the metadata. The old location is then the object on the source site, and cloudserver tries to delete it. Today the delete only fails by luck: cloudserver has no data client for CRR locations, so the delete throws an error, and backbeat gets an error for a metadata write that actually succeeded.
Data on a CRR location belongs to another site.
Backbeat already refuses to delete it (added recently with the pull replication Epic), in the lifecycle transition processor and in the GC (locationsConfig[dataStoreName]?.isCRR).