The use of packrat in Posit Connect can hit race-conditions during restore. It seems packrat directly writes to/reads from the DESCRIPTION file of packages and if two Connect apps are using the same package and are updated/redeployed at the same time, we could hit a race-condition where one or both updates fail. i.e.
2023/08/04 14:09:06.743139312 # Installing required R packages with `packrat::restore()` ---------------------
2023/08/04 14:09:07.220617061 Installing DBI (1.1.1) ...
2023/08/04 14:09:07.245971037 Error in annotatePkgDesc(pkgRecord, project, lib): nrow(content) == 1 is not TRUE
2023/08/04 14:09:07.245980057
2023/08/04 14:09:07.246015294 Unable to fully restore the R packages associated with this deployment.
2023/08/04 14:09:07.246019737 Please review the preceding messages to determine which package
2023/08/04 14:09:07.246055930 encountered installation difficulty and the cause of the failure.
2023/08/04 14:09:07.249423406 Warning message:
2023/08/04 14:09:07.249481533 In packrat::restore(overwrite.dirty = TRUE, prompt = FALSE, restart = FALSE) :
2023/08/04 14:09:07.249487850 The most recent snapshot was generated using R version 4.1.1
In this case a retry succeeded, so this was not an instance of a corrupt packrat cache.
This is especially fragile in a Connect instance with many git-backed deployments as multiple apps could be redeployed concurrently when Git.Concurrency>1.
The use of packrat in Posit Connect can hit race-conditions during restore. It seems packrat directly writes to/reads from the DESCRIPTION file of packages and if two Connect apps are using the same package and are updated/redeployed at the same time, we could hit a race-condition where one or both updates fail. i.e.
In this case a retry succeeded, so this was not an instance of a corrupt packrat cache.
This is especially fragile in a Connect instance with many git-backed deployments as multiple apps could be redeployed concurrently when Git.Concurrency>1.