@hundreds-father-404: should i take a swing at https://github.com/pantsbuild/pants/issues/12019, or would you like to look at it?

Not sure how we want to prioritize. Other things I could work on • setup-py interpreter constraints issue that blocks a user upgrading Pants • logging for plugins not going to correct place sometimes • Per-tool lock files

would continue with whatever you have context for then, that’s fine

I'll continue with this one then. Thanks! Will follow it up with setup-py, which I promised a user

but do please put more context on 12019 if you have it.

I do, but it requires using Toolchain's remote caching service in local mode. Hence my pause to put on the open source project's ticket

ah, got it. can DM me

I'm still debugging, but this is interesting. Adding this does not ever result in a panic when running

./pants --stats-log --no-remote-cache-read --no-process-execution-local-cache --no-pantsd lint src/python/pants/util/strutil.py

against a remote cache server with intentional slowdown of remote cache writes

diff --git a/src/rust/engine/workunit_store/src/lib.rs b/src/rust/engine/workunit_store/src/lib.rs
index 3d56e8947..6b61d1c87 100644
--- a/src/rust/engine/workunit_store/src/lib.rs
+++ b/src/rust/engine/workunit_store/src/lib.rs
@@ -864,6 +864,7 @@ impl Drop for RunningWorkunit {
   fn drop(&mut self) {
     if let Some(workunit) = self.workunit.take() {
+      panic!("Dropped! {:?}", workunit);
       self.store.cancel_workunit(workunit);
     }
   }
 }

that would mean that it successfully completed

hey @witty-crayon-22786 @fast-nail-55400 I think what's going on actually makes a ton of sense and there is no "bug" as we thought. Can you please check my thinking and proposed fix in https://github.com/pantsbuild/pants/issues/12019#issuecomment-860940069?

added a comment with a question