`lock_test.rb` tests failures
Closed this issue · 4 comments
When trying to run the tests for this project against a mysql database, the following 3 tests fail:
Lock::.remove_expired_locks#test_0001_removes expired locks
1) Error:
Lock::.remove_expired_locks#test_0001_removes expired locks:
ActiveRecord::RecordNotUnique: Mysql2::Error: Duplicate entry '554917358-Stage-2018-04-17 06:41:25' for key 'index_locks_on_resource_id_and_resource_type_and_deleted_at': UPDATE `locks` SET `deleted_at` = '2018-04-17 06:41:25' WHERE `locks`.`id` = 32
Lock::.remove_expired_locks#test_0002_leaves unexpired locks alone
2) Error:
Lock::.remove_expired_locks#test_0002_leaves unexpired locks alone:
ActiveRecord::RecordNotUnique: Mysql2::Error: Duplicate entry '554917358-Stage-2018-04-17 06:41:25' for key 'index_locks_on_resource_id_and_resource_type_and_deleted_at': UPDATE `locks` SET `deleted_at` = '2018-04-17 06:41:25' WHERE `locks`.`id` = 37
Lock::.remove_expired_locks#test_0003_leaves indefinite locks alone
3) Error:
Lock::.remove_expired_locks#test_0003_leaves indefinite locks alone:
ActiveRecord::RecordNotUnique: Mysql2::Error: Duplicate entry '554917358-Stage-2018-04-17 06:41:25' for key 'index_locks_on_resource_id_and_resource_type_and_deleted_at': UPDATE `locks` SET `deleted_at` = '2018-04-17 06:41:25' WHERE `locks`.`id` = 42
Tested environments:
- MacOS 10.13, Ruby 2.5.0
- Ubuntu Trusty, Ruby 2.5.0
- version
v2218
The SQL executed in the first test was: (removed savepoints and releases since they're not relevant here)
BEGIN
SELECT `users`.* FROM `users` WHERE `users`.`id` = 554286751 LIMIT 1
SELECT `stages`.* FROM `stages` WHERE `stages`.`id` = 554917358 LIMIT 1
INSERT INTO `locks` (`resource_id`, `user_id`, `created_at`, `updated_at`, `delete_at`, `resource_type`) VALUES (554917358, 554286751, '2018-04-17 23:09:04', '2018-04-18 01:09:04', '2018-04-18 02:09:04', 'Stage')
SELECT `stages`.* FROM `stages` WHERE `stages`.`id` = 685639643 LIMIT 1
INSERT INTO `locks` (`resource_id`, `user_id`, `created_at`, `updated_at`, `delete_at`, `resource_type`) VALUES (685639643, 554286751, '2018-04-17 23:09:04', '2018-04-18 01:09:04', '2018-04-18 02:09:04', 'Stage')
INSERT INTO `locks` (`resource_id`, `user_id`, `created_at`, `updated_at`, `delete_at`, `resource_type`) VALUES (554917358, 554286751, '2018-04-18 01:09:04', '2018-04-18 01:09:04', '2018-04-18 02:09:04', 'Stage')
INSERT INTO `locks` (`resource_id`, `user_id`, `created_at`, `updated_at`, `delete_at`, `resource_type`) VALUES (685639643, 554286751, '2018-04-18 01:09:04', '2018-04-18 01:09:04', '2018-04-18 02:09:04', 'Stage')
SELECT `stages`.* FROM `stages` WHERE `stages`.`id` = 398743887 LIMIT 1
INSERT INTO `locks` (`resource_id`, `user_id`, `created_at`, `updated_at`, `resource_type`) VALUES (398743887, 554286751, '2018-04-18 01:09:04', '2018-04-18 01:09:04', 'Stage')
SELECT `locks`.* FROM `locks` WHERE `locks`.`deleted_at` IS NULL AND (delete_at IS NOT NULL and delete_at < CURRENT_TIMESTAMP) ORDER BY `locks`.`id` ASC LIMIT 1000
SELECT `users`.* FROM `users` WHERE `users`.`deleted_at` IS NULL AND `users`.`id` = 554286751
UPDATE `locks` SET `deleted_at` = '2018-04-18 01:09:04' WHERE `locks`.`id` = 512
UPDATE `locks` SET `deleted_at` = '2018-04-18 01:09:04' WHERE `locks`.`id` = 513
UPDATE `locks` SET `deleted_at` = '2018-04-18 01:09:04' WHERE `locks`.`id` = 514
ROLLBACK
With the last UPDATE for id 514 causing the exception.
The unique key on the locks table seems to be the thing that doesn't really make sense. It should be possible to delete multiple locks at the same time.
UNIQUE KEY `index_locks_on_resource_id_and_resource_type_and_deleted_at` (`resource_id`,`resource_type`(40),`deleted_at`)
This is especially true if the locks have only 1 second granularity. Since multiple locks on the same resource are possible, should this be treated as a standard (not unique) key instead?
It looks like this unique check was there for a while already: https://github.com/zendesk/samson/blob/master/db/migrate/20161019000833_add_environment_to_lock.rb#L12
so I guess your machine is too fast
the fixtures are unrealistic ... there cannot be 2 locks on the same resource ... I'll fix that up