Expiring a mostly-finished task run.

If I have a large task run, expiring it expires all its units, which sets the expiry on mturk even if the unit is completed. This can take a long time. I am wondering if this is worth optimizing. If so, would the following change in mephisto, in mturk_unit.py, be safe?

     def expire(self) -> float:
         """
         Send a request to expire the HIT, and if it's not assigned return,
         otherwise just return the maximum assignment duration
         """
         delay = 0

+        status = self.get_status()
+        if status in [AssignmentState.EXPIRED, AssignmentState.COMPLETED]:
+            return delay

-        if self.get_status() == AssignmentState.ASSIGNED:
+        if status == AssignmentState.ASSIGNED:

[JackUrb]

@federicoruggeri this is something of a bug in behavior, but not of intent. When an agent disconnects, if the system doesn’t explicitly expire the Unit, we assume that the Unit should be put up for a different agent to be able to accept. In the case of a dialogue task though, we do expire the Unit directly, but then the get_status overrides that. We should reject the edge transition to LAUNCHED here though specifically if the unit is already in the expired state: https://github.com/facebookresearch/Mephisto/blob/fc359c74dc73c4c408b089301833682107bbbbfa/mephisto/data_model/unit.py#L285-L289

Good job in identifying the logical transition though, this fix would definitely be appreciated.

[bottler]

I’ve been testing this out, running large runs for a few days, and it seems to be working. I will make a PR.

There are often cases where I expire a run* and wait a while (much longer than the assignment duration) and find that there’s a hit or two in the “launched” state. In this case, expiring the run again succeeds in cleaning up.

• i.e. operator.get_running_task_runs()[...].task_launcher.expire_units()