ee2e85a0bb
Summary:
People hit three issues with D3914:
- As per T2059, we applied a schema change from a `.php` patch, which currently does not work if you use a different user to make schema changes than for normal use.
- Since the change in question is idempotent, just move it to a `.sql` patch. We'll follow up in T2059 and fix it properly.
- Rogue daemons at several installs used old code (expecting autoincrement) to insert into the new table (no autoincrement), thereby creating tasks with ID 0.
- Rename the table so they'll fail.
- This also makes the code a little more consistent.
- Some installs now have tasks with ID 0.
- Use checks against null rather than against 0 so we can process these tasks.
The major issues this fixes are the schema upgrade failure in T2059, and the infinite loops in T2072 and elsewhere.
This isn't really a fully statisfactory fix. I'll discuss some next steps in T2072.
Test Plan: Created new tasks via MetaMTA/Differential. Ran tasks with `phd debug taskmaster`. Inserted a task 0 and verified it ran and archived correctly.
Reviewers: btrahan, vrana, nh
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2072, T2059
Differential Revision: https://secure.phabricator.com/D3973
9 lines
296 B
SQL
9 lines
296 B
SQL
ALTER TABLE `{$NAMESPACE}_worker`.worker_task
|
|
CHANGE id id INT UNSIGNED NOT NULL;
|
|
|
|
RENAME TABLE `{$NAMESPACE}_worker`.worker_task
|
|
TO `{$NAMESPACE}_worker`.worker_activetask;
|
|
|
|
UPDATE `{$NAMESPACE}_worker`.lisk_counter
|
|
SET counterName = 'worker_activetask' WHERE counterName = 'worker_task';
|