Event hash mismatches cause perpetually failed events

[WPprodigy]

Scenario: Somebody does a Search/Replace on the DB, and replaces say wp_ with wp_3. Other problems with that aside, events in the cron control table now have an action of wp_4_update_themes but a hash of 1415f2766f26fbe75db22be4aae62aeb(which was made from wp_update_themes).

Since get-due-batch re-hashed before sending (md5( $event['action'] )), the runner will then pass the new hash. But said event won't be found and the job will fail. However, the event is still due and at the top of the "due now" list. So the runner will keep trying over and over again to run the doomed event each batch.

[WPprodigy]

Solutions:

1. Sanity check in list-due-batch, perhaps if there is a relatively old event at the top it should scan the batch and resolve entries that have mismatches.

2. list-due-batch should eventually be querying the table directly, and it can just send along the action_hashed from the table directly. This way the runner always gets valid args that match something in the table.

[WPprodigy]

Leaning towards just giving the runner an event ID to run: cron-control orchestrate runner-only run 123

it doesn't need all the other info. And w/ an ID, we can always be sure we'll end up with the right event.

[WPprodigy]

This problem also creeps up if the cron control table is set to an incorrect encoding like Latin1.

So when a cron event was added with args containing a UTF8 string, the serialized data can be corrupted and the runner is again unable to run the event because the instance doesn't match up.