Making MTurk cleanup run daily per requester #918
Merged
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.
Overview
It very frequently comes up that Mephisto users and workers are left in positions where tasks seem to be broken. Usually this is the result of stale tasks, which surface from hasty shutdowns or strange expiration issues through
botocore
. Themephisto scripts mturk cleanup
script exists to alleviate this problem, but given how frequently the issue arises I think it makes sense to build this functionality into the Mephisto run script when using an MTurk requester.Implementation
try_prerun_cleanup
script to themturk_utils
that queries for presumed active (or broken HITs) and surfaces these if it has been greater than 24 hours since the last time one of these queries has been run for the given requester. It allows the user to select which if any HITs need disposing, then continues. It updates a file in~/.mephisto/
to keep track of these times.augment_config_from_db
helper function to runtry_prerun_cleanup
whenever an MTurk requester is being used.Testing
I cleaned up some of my old tasks on one of my requesters using the new
(o)ld
option.I tried launching a task using one of my requesters:
First time
After first run
Note
One can disable this functionality until a future date by updating the "last reviewed time" for a given requester to sometime in the future. If it becomes an issue, we will provide an option to
(d)efer
the check, however I think doing this check is important for worker quality.