CLDSRV-976: bump arsenal to 8.4.24 - #6256
Conversation
Hello tcarmet,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Incorrect fix versionThe
Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:
Please check the |
| "@hapi/joi": "^17.1.1", | ||
| "@smithy/node-http-handler": "^3.0.0", | ||
| "arsenal": "git+https://github.com/scality/Arsenal#8.4.22", | ||
| "arsenal": "git+https://github.com/scality/Arsenal#a8390e2b45f083b799177b5966c56f5fd9e75257", |
There was a problem hiding this comment.
Arsenal is pinned to a commit hash instead of a tag. All other git-based deps in this file use tags (e.g. bucketclient#8.2.7, vaultclient#8.5.7). Since yarn.lock resolves this to version 8.4.24, pin to the tag once it's available.
| "arsenal": "git+https://github.com/scality/Arsenal#a8390e2b45f083b799177b5966c56f5fd9e75257", | |
| "arsenal": "git+https://github.com/scality/Arsenal#8.4.24", |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
@@ Coverage Diff @@
## development/9.3 #6256 +/- ##
===================================================
- Coverage 85.17% 85.12% -0.06%
===================================================
Files 206 206
Lines 13424 13424
===================================================
- Hits 11434 11427 -7
- Misses 1990 1997 +7
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Arsenal 8.4.24 pulls in sproxydclient 8.2.2, which treats any 2xx response from sproxyd as a success instead of whitelisting 200 and 206. sproxyd answers DELETE and POST .batch_delete with 204 (no content), which the previous whitelist turned into an error, and DataWrapper then retried three times before surfacing an InternalError that reached the S3 client as a 500. Also bumps the project version to 9.3.17. Issue: CLDSRV-976
b60b64f to
5bb2dd3
Compare
sproxyd now answers DELETE and batch-delete requests with 204 No Content, and the sproxyd client carried by the previous Arsenal only accepted 200 and 206 as success. Deletes were therefore retried and eventually surfaced to S3 clients as internal errors. This picks up the Arsenal version carrying the fixed client so deletes succeed again.