While the RESTBase + Parsoid conbo has content versioning and respects content version headers, that is semantically versioned and only matters for major version bumps. For minor version bumps, occasionally, Parsoid may not have support for the right minor version because of train rollbacks without building special support for forward compatibility.

Next week, we anticipate rolling out a Parsoid 2.4.0 HTML version that Parsoid v0.15.0-a10 (shipped with MW 1.38.0-wmf.9) doesn't have support for. So, if the train is rolled back for whatever reason, RESTBase will have 2.4.0 content for the timeframe when the new train was active on wikis. So, on train rollback, RESTBase 2.4.0 content would need to be purged for wikis that had the train rolled back. My understanding is that RESTBase cannot purge by HTML version (since it probably doesn't record that info), but can purge based on a time window.

In case it is not possible to only purge this only for wikis that had the train rolled back, it is okay to purge unconditionally - it may lead to a temporary spike in HTML parse requests to Parsoid to fulfill requests for content that might have hit in RESTBase.

Ideally, we need this script in place before the train rolls out on Tuesday next week so we aren't scrambling at the last minute if the train rolls back later in the week.