Page MenuHomePhabricator

Fix an issue where "bin/differential migrate-hunk" could decompress data
ClosedPublic

Authored by epriestley on Sep 18 2017, 7:27 PM.
Tags
None
Referenced Files
F13148588: D18624.diff
Sat, May 4, 2:41 AM
Unknown Object (File)
Wed, May 1, 1:01 AM
Unknown Object (File)
Tue, Apr 23, 6:42 PM
Unknown Object (File)
Tue, Apr 23, 6:42 PM
Unknown Object (File)
Tue, Apr 23, 6:41 PM
Unknown Object (File)
Tue, Apr 23, 6:41 PM
Unknown Object (File)
Sat, Apr 20, 4:47 PM
Unknown Object (File)
Fri, Apr 19, 2:42 AM
Subscribers
None

Details

Summary

Fixes T12986. I caught this bug in the changes from D18584: when we moved a large hunk to file storage, we would decompress it but keep the "deflated" flag. This could cause confusion when loading it later. I missed this in testing since I wasn't exhaustive enough in checking hunks and didn't run into a compressed one.

Instead of compressing on save(), compress during the normal workflow.

We currently never advise users to run this workflow so I didn't bother trying to clean up possible existing migrations.

Test Plan
  • Ran bin/differential migrate-hunk on compressed hunks, moving them to and from file storage. Saw them work correctly and remain compressed.
  • Created new small (uncompressed) and large (compressed) hunks, verified they work properly and get compressed (if applicable).
  • Used bin/cache purge --caches changeset to clear changeset caches and make sure the actual table was being hit.

Diff Detail

Repository
rP Phabricator
Branch
hunk1
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 18491
Build 24900: Run Core Tests
Build 24899: arc lint + arc unit