Hello. When I revdepfuture, therevdepcheck packages runs two concurrentR CMD check:s onFastRet. One checks against the CRAN version offuture, and the other against the develop version offuture. Not each time, but occasionally, one of these two concurrent runs fail with:

+*   checking replacement functions ... WARNING+    ```+    Warning in dir.create(cache_dir, recursive = TRUE) :+      '/c4/home/henrik/.cache/R/FastRet' already exists+    The argument of a replacement function which corresponds to the right+    hand side must be named ‘value’.+    ```++*   checking dependencies in R code ... NOTE+    ```+    Warning in dir.create(cache_dir, recursive = TRUE) :+      '/c4/home/henrik/.cache/R/FastRet' already exists+    ```

I can imagine there's some kind of race condition going on whenFastRet tries to read and write cache files from two different processes at the same time.

One way to lower the risk for race-conditions trying to access the same cache file is to write files atomically, e.g.

target<- file.path(cache_dir,"somefile.rds")tmp_target<- paste0(target,".tmp")saveRDS(data,file=tmp_target)## slowfile.rename(tmp_target,target)## very quick - instant

This removes the risk of having another process trying to read a half-written cache file. I'm not sure if this is the reason, but it doesn't hurt to do this. I use this strategy myself in many places, so I ended up writing an internal help functionsave_rds() that does it for me. Feel free to copyhttps://github.com/futureverse/future/blob/7c83100ba4f2bcf89d3a0ce7e468f84e81746561/R/utils-immediateCondition.R#L160-L208 if you'd like.

I want to let you know, in case others might experience this, e.g. when a user runs multipleFastRet analysis on a compute cluster. This could be hard to troubleshoot for the end user.