this is an attempt to bugfix 3235 - after moving more status stuff into the block provider executor, then perhaps its easier to do local reasoning here about which info the job status poller actually wants?

specifically, what's different about FAILED vs PENDING artificial statuses?

FAILED is persistent beyond the update from the underlying provider
PENDING should be replaced by an update from the underlying provider - including, perhaps incorrectly, being entirely deleted

and that's probably the fundamental problem i have so far with unifying these tables - the different update semantics above

to bugfix this, in addition to seeing the poller deferred status, we also need to see the simulated status changes live
(rather than cache-deferred)

no one else is using simulated status and now job status poller is allowed to touch the internal structs, so perform the simulated status update elsewhere

broken behaviour is that other callers (if they exist?) of executor.status no longer see any simulated status at all

this behaviour changes when htex gets to apply the MISSING rewrite to only include jobs reported by the provider, not jobs added by simulated status. that's actually possibly desirable, because simulated status might contain more useful information that shouldn't be overwritten by MISSING?

Author: benclifford

parsl/executors/status_handling.py

@@ -124,7 +124,6 @@ def _old_status_impl(self) -> Dict[str, JobStatus]:
             status = self._make_status_dict(block_ids, self._provider.status(job_ids))
         else:
             status = {}
-        status.update(self._simulated_status)
 
         return status
 
@@ -133,6 +132,7 @@ def status(self) -> Dict[str, JobStatus]:
         if self._should_poll(now):
             self._poller_mutable_status = self._old_status_impl()
             self._last_poll_time = now
+        self._poller_mutable_status.update(self._simulated_status)
         return self._poller_mutable_status
 
     def set_bad_state_and_fail_all(self, exception: Exception):