Maintain property names for serialized schedules #345
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Rather than duplicating the docblock in CronSchedule & IntervalSchedule, link to it.
|
This is failing the unit tests on missing |
Prior to #333, recurring schedules used different property names to refer to equivalent data. For example, IntervalSchedule::start_timestamp was the same as SimpleSchedule::timestamp. PR #333 aligned properties and property names for better inheritance. To guard against the possibility of infinite loops if downgrading to Action Scheduler < 3.0.0, we need to also store the data with the old property names so if it's unserialized in AS < 3.0, the schedule doesn't end up with a 0 recurrence. Fixes #340.
|
I've fixed that up @rrennick. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prior to #333, recurring schedules used different property names to refer to equivalent data. For example,
IntervalSchedule::start_timestampwas the same asSimpleSchedule::timestamp.PR #333 aligned properties and property names for better inheritance. However, in doing so, it also broke backward compatibility with schedule data serialized and stored prior to AS 3.0.0.
While that was a known issue, what wasn't realised at the time is that sites may downgrade to AS < 3.0.0. In some cases, they may do this completely unintentionally or unaware. For example, because they deactivate a plugin with AS >= 3.0.0 and another plugin is still running AS < 3.0.0.
For most cases, this won't be a major issue. Their data will have been migrated to a custom data store when upgrading to AS 3.0.0, so when downgrading, AS < 3.0.0 won't select and attempt to continue running with any data stored with AS >= 3.0.0.
However, there is the case of a site which has the custom tables plugin installed. Those sites will continue to claim the data in the new format, even though AS will be looking for properties on schedules in the old format.
This creates the infinite loops mentioned in #340.
To guard against the possibility of infinite loops if downgrading to Action Scheduler < 3.0.0, we need to also store the data with the old property names so if it's unserialized in AS < 3.0, the schedule doesn't end up with a 0 recurrence.
This PR handles that.
It also sneaks in a couple of commits to tweak docblocks added in #333.
Fixes #340.