3.27.3 - A sync that dies inside one listing gets through it, and says where

A sync that dies inside one listing gets through it, and says where

• FIX: On WordPress.com, and other hosts on Automattic's memcached object cache, every sync run could die inside the first listing it started, at the memory limit. The sync's own work on a listing uses well under a megabyte; the memory went into the cache's copies of thousands of posts that something else on the site reads while a product is saved. While the sync imports - the regular sync, Fetch Inventory, and a single listing's import - it now watches the cache, and when one listing has taken memory well past where it started and past half the limit, it empties those copies part way through. The values stored in memcached are untouched. The activity log says when that gave memory back, and on which listing.
• FIX: The object cache's copies are now released before every listing, the first included, not every tenth - and in Fetch Inventory too, which released them only between pages of 200.
• FIX: A run that stops because memory is running short no longer has its next run picked up in the same request.
• When a run is killed, the log line now says which step of the listing it was on, when the listing began and at what memory, which WordPress hooks were running (another plugin's work on a product save shows there), and what the object cache held. It gives the memory limit that was reached, not a raised one in bytes.

---

1779 assertions across 33 files, all checks green.