Issue
It looks like the cache created by ExperimentHub is not parallel-safe, i.e. if you run multiple R processes, or R sessions concurrently, you might end up with:
Corrupt Cache: sqlite file
- See AnnotationHub's TroubleshootingTheCache vignette section on corrupt cache
- cache: /c4/home/henrik/.cache/R/ExperimentHub
- filename: experimenthub.sqlite3
- --- failed re-building ‘IntOMICS_vignette.Rmd’
Details
When I run reverse dependency checks on matrixStats, I experience the above with high probability. I use revdepcheck for this. It works by running two concurrent sessions of R CMD check on each package tested. One of the checks ("old") is with the CRAN version of matrixStats and the other ("new") is with the development version of matrixStats. Then revdepcheck compares the result of these two to see if there's any negative impact from the developer's version of matrixStats.
Thus, when running this in parallel, the "old" and the "new" are likely to use the same ExperimentHub cache at the same time. When that happens, there is a great risk of getting the above error. Note that this is also relevant for anyone running a parallel analyses/tasks that all use ExperimentHub.
To give further evidence that this is a race-condition problem, the problem is 100% avoided if I check the reverse-dependency packages sequentially so that "old" and "new" runs are not run at the same time. You can see the difference that running in parallel and sequentially makes in HenrikBengtsson/matrixStats@0cb249b.
Issue
It looks like the cache created by ExperimentHub is not parallel-safe, i.e. if you run multiple R processes, or R sessions concurrently, you might end up with:
Details
When I run reverse dependency checks on matrixStats, I experience the above with high probability. I use revdepcheck for this. It works by running two concurrent sessions of
R CMD checkon each package tested. One of the checks ("old") is with the CRAN version of matrixStats and the other ("new") is with the development version of matrixStats. Then revdepcheck compares the result of these two to see if there's any negative impact from the developer's version of matrixStats.Thus, when running this in parallel, the "old" and the "new" are likely to use the same ExperimentHub cache at the same time. When that happens, there is a great risk of getting the above error. Note that this is also relevant for anyone running a parallel analyses/tasks that all use ExperimentHub.
To give further evidence that this is a race-condition problem, the problem is 100% avoided if I check the reverse-dependency packages sequentially so that "old" and "new" runs are not run at the same time. You can see the difference that running in parallel and sequentially makes in HenrikBengtsson/matrixStats@0cb249b.