[Bug]: revdep checks Status: ? (Failed to check)

[munoztd0]

What happened?

Just wanted to share a quick observation I ran into while setting up our own revdep checks using r-revdepcheck-action.

I noticed that most downstream packages were consistently reporting Status: ? (Failed to check) but keeping the pipeline green. It turned out that the default 20-minute (1200s) timeout was killing the background miniCRAN installation phase before it could finish compiling the dependency tree.

Looking at recent tern runs, it seems like the exact same thing might be happening there (e.g., junco or tern.mrmm silently failing to install and showing ? instead of running tests). Explicitly passing a higher timeout: i.e 7200 to the action completely resolved these "ghost" failures for me.

revdepcheck actions (in tern here but it's the same for all the NEST packages) but it pretty much fails to load anything but scda.test

@gmbecker

Code of Conduct

• I agree to follow this project's Code of Conduct.

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines.

Security Policy

• I agree to follow this project's Security Policy.

[Melkiades]

I am not super sure why it is showing like that. I am sure @walkowif knows best!

[walkowif]

I think increasing the default timeout here could be a good idea.

Regarding why the workflow run succeeds despite Failed to check packages - likely because of the internal implementation of https://github.com/insightsengineering/r-revdepcheck-action/blob/main/script.R

[munoztd0]

I think increasing the default timeout here could be a good idea.

Regarding why the workflow run succeeds despite Failed to check packages - likely because of the internal implementation of https://github.com/insightsengineering/r-revdepcheck-action/blob/main/script.R

Do you want me to investigate / do a PR on it or you want to do it internally ?

[gmbecker]

So I'm a bit confused here. I wasn't involved in the revdepcheck development process, nor have I used it, but I did develop and maintain a precursor to it as part of my management of the genentech research server R installations years ago.

For a package like tern, I'm struggling to see what part of the process should take 20 minutes. It only has a handful of reverse dependencies.

Is it the non-reverse dependency installation that is choking the pipeline? That should be cached right?

For reference (on obviosuly faster hardware):

> system.time(pkgandrevdeps <- unique(unlist(c("tern", package_dependencies("tern", recursive = TRUE, reverse = TRUE)))))
   user  system elapsed 
  0.262   0.010   0.273 
> pkgandrevdeps
 [1] "tern"                  "aNCA"                  "autoslider.core"       "chevron"               "junco"                
 [6] "teal.modules.clinical" "teal.modules.general"  "tern.gee"              "tern.mmrm"             "uteals"               
> system.time(inst_needed <- unique(unlist(package_dependencies(pkgandrevdeps, recursive = TRUE, reverse = FALSE))))
   user  system elapsed 
  0.273   0.013   0.288 
> length(inst_needed)
[1] 281
> head(inst_needed)
[1] "rtables"   "broom"     "car"       "checkmate" "cowplot"   "dplyr"    

If the installation of dependencies is cached, the whole process of setup should be reasonably fast, right? The above is fast and loose and doesn't handle versioned dependencies, but even so it took my laptop ~ .5 seconds, and its unclear that it should take ~600x+ longer, even assuming the action is multiple times slower in the case where the cached installed dependencies are sufficient.

Or did I misunderstand and the checking of the handful of reverse dependencies is what is actually taking so long, not the setup/calculation of what is needed?

[munoztd0]

@gmbecker I do think it's the checking time that is choking the pipeline, i.e. scda.test is already taking ~10min on our pipelines and if I'm right the revdep process does it twice (once on CRAN version and once with the version at hand).