Handle 404 from Scuba backend#5968
Conversation
For Veeam reoutes, this will set 0 as the metric. The value is correct: if scuba returns a 404 error, it means there is no metric for the resource. Issue: CLDSRV-758
Hello williamlardier,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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
... and 1 file with indirect coverage changes @@ Coverage Diff @@
## development/9.1 #5968 +/- ##
===================================================
+ Coverage 83.72% 84.00% +0.27%
===================================================
Files 191 191
Lines 12233 12238 +5
===================================================
+ Hits 10242 10280 +38
+ Misses 1991 1958 -33
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
| it('GET capacity.xml should return 200 when scubaclient returns 404 (post-install scenario)', done => { | ||
| // This test simulates the post-install scenario where scubaclient returns 404 | ||
| // because no metrics are available yet. By not calling scuba.incrementBytesForBucket, | ||
| // the mock scuba server will return 404 for this bucket. |
There was a problem hiding this comment.
Should we do something to make sure it's the case ? My point is that if someone change the mock server, this test will continue to pass 🤷
There was a problem hiding this comment.
Already tracked by this ticket: https://scality.atlassian.net/browse/CLDSRV-528
A bit too early to add scuba yet, we need to drop count items first
| getVeeamFile(request, response, bucketMd, log); | ||
|
|
||
| setImmediate(() => { | ||
| // For 500 errors, we should return error to client |
There was a problem hiding this comment.
| // For 500 errors, we should return error to client |
You already mention that in the it
SylvainSenechal
left a comment
There was a problem hiding this comment.
Nothing much to add from Edouard's review, I still very much prefer functional tests over mocks, and I find mocks hard to read, but it's better than nothing
Nits : some variables could be replaced by constants in veeam-route.js : 'test-bucket', 'getBucket'.
I also prefer to not use default parameter for the object key in createRequest, but not very important
Issue: CLDSRV-758
1012aab to
3f8ed81
Compare
|
/approve |
In the queueThe changeset has received all authorizations and has been added to the The changeset will be merged in:
The following branches will NOT be impacted:
There is no action required on your side. You will be notified here once 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 The following options are set: approve |
Queue build failedThe corresponding build for the queue failed:
Remove the pull request from the queue
|
|
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
Please check the status of the associated issue CLDSRV-758. Goodbye williamlardier. |
For Veeam reoutes, this will set 0 as the metric. The value is correct: if scuba returns a 404 error, it means there is no metric for the resource.
Issue: CLDSRV-758