CLDSRV-992: Build the uploadPartCopy fixtures once per suite, not per test - #6280
Conversation
… test Both `uploadPartCopy` describes in the PartNumber tests rebuild a large MPU fixture in a beforeEach, although all four of their tests only issue a GetObject. Each rebuild moves roughly 200 MB: completeMPU uploads ten 5 MB parts one at a time with async.eachSeries, createMPUAndPutTwoParts copies that 50 MB object and then puts a 50 MB body, and the overwrite variant adds a 5 MB part and a second 50 MB UploadPartCopy. Doing that twice per describe, once for each read-only test, is what pushes the hook past the 40 s mocha timeout on the s3c backend. Move the setup to `before` and the DeleteObject cleanup to `after`. The fixture is identical for both tests in each describe, and the enclosing describe creates the bucket in its own `before` and drops it in `after`, so the fixture safely outlives the individual tests. Halves the data moved by these two describes and removes the redundant rebuild, rather than raising the timeout. Clears the timeout half of CLDSRV-992 row F8 (run 33647777908): the "before each" hook for "should retrieve a part that overwrote another part originally copied from an MPU". The same row's ServiceUnavailable on "should get the body of part 8 when ordered MPU" is a separate transient and is not addressed here. Issue: CLDSRV-992
Hello anurag4dsb,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 expected to find at least:
Please check the |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## hotfix/9.2.36 #6280 +/- ##
==============================================
Coverage 84.37% 84.37%
==============================================
Files 204 204
Lines 13162 13162
==============================================
Hits 11106 11106
Misses 2056 2056
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
8245437 to
4bbb2af
Compare
|
Moving back to draft along with #6281 — same reasoning. The change was justified as fixture cost, but the CI logs show the fixture is not slow (the same build succeeds three or four times per run then stalls once), so this halves exposure to an unexplained stall while giving up per-test independence. These s3c jobs capture no cloudserver log, which is why the stall cannot be diagnosed today. #6283 adds that capture first. |
Intent: why does this change exist?
NEW FIX. Both
uploadPartCopydescribes in the PartNumber tests rebuild a ~200 MB MPU fixture in abeforeEach, though all four of their tests only issue a GetObject. The redundant second build is what exceeds the 40 s mocha timeout. Clears the timeout half of CLDSRV-992 row F8 (run 33647777908).System impact: what's affected, including downstream?
One functional test file, setup and teardown only. No product code, no assertions touched. development/9.3 needs the same change and has #6281.
Preserved behavior: what explicitly stays the same?
The fixture is identical and both tests read exactly what they read before. No timeout raised, no retry added, nothing skipped. That row's separate ServiceUnavailable on "part 8 when ordered MPU" is a different transient and is not addressed here.
Intended change: what's different after this PR?
Setup moves to
beforeand cleanup toafter, so each describe builds its fixture once. The enclosing describe already owns the bucket in its ownbefore/after, so the fixture safely outlives the tests.Verification: how do we know this worked, or how would we know if it didn't?
The cost is arithmetic from the fixture itself: a serial 10x5 MB completeMPU, a 50 MB UploadPartCopy, a 50 MB UploadPart, then a further 5 MB part and second 50 MB copy. Both tests are pure GetObject calls, so the second build did no work they depended on. s3c-ft-tests-v0 stressed 10x on this branch.