Skip to content

cloud_check() should mercy kill a revdep that needs a package from a defunct repo #400

@jennybc

Description

@jennybc

This is based on my recent experience doing revdepchecks for vroom. As of 2026-01-23, vroom has impactr as a revdep:

https://cran.r-project.org/web/packages/impactr/index.html

And here's its DESCRIPTION right now:

Package: impactr
Title: Mechanical Loading Prediction Through Accelerometer Data
Version: 0.4.1
Authors@R: 
    person(given = "Lucas",
           family = "Veras",
           role = c("aut", "cre"),
           email = "[email protected]",
           comment = c(ORCID = "0000-0003-0562-5803"))
Description: Functions to read, process and analyse accelerometer
    data related to mechanical loading variables. This package is
    developed and tested for use with raw accelerometer data from
    triaxial 'ActiGraph' <https://actigraphcorp.com> accelerometers.
License: MIT + file LICENSE
URL: https://lveras.com/impactr/
BugReports: https://github.com/verasls/impactr/issues/
Encoding: UTF-8
LazyData: true
Roxygen: list(markdown = TRUE)
RoxygenNote: 7.2.1
Imports: 
    glue,
    lubridate,
    lvmisc,
    pillar,
    pracma,
    purrr,
    Rcpp,
    rlang (>= 0.4.6),
    signal,
    stringr,
    tibble,
    toOrdinal,
    utils,
    vroom
Suggests: 
    accdata,
    covr,
    knitr,
    rmarkdown,
    testthat (>= 3.0.0)
Config/testthat/edition: 3
LinkingTo: 
    Rcpp
VignetteBuilder: knitr
Language: en-GB
Depends: 
    R (>= 2.10)
Additional_repositories: https://lveras.com/drat/

It Suggests accdata, which is supposed to be available from the Additional_repositories: https://lveras.com/drat/. But that repository does not currently exist.

~/work/vroom % curl -I https://lveras.com/drat/src/contrib/PACKAGES
HTTP/2 403 
alt-svc: h3=":8443"; ma=2592000
server: Caddy
date: Sat, 24 Jan 2026 01:46:19 GMT

~/work/vroom % curl -I https://cloud.r-project.org/src/contrib/PACKAGES 
HTTP/2 200 
content-length: 5711710
date: Sat, 24 Jan 2026 01:46:59 GMT
expires: Sat, 24 Jan 2026 02:16:59 GMT
server: Apache/2.4.65 (Unix)
last-modified: Sat, 24 Jan 2026 00:31:16 GMT
etag: "57275e-6491764598047"
accept-ranges: bytes
cache-control: max-age=1800
x-cache: Miss from cloudfront
via: 1.1 36d4ca7ddc4beff9d1b963574f5a4134.cloudfront.net (CloudFront)
x-amz-cf-pop: YVR52-P3
x-amz-cf-id: 8Orpg5Pk3i4uJsa-iNH_gNdShgzquldFfQSZbpthkDiiuY13pgmJtA==

Here's how it looks when I try to install local dev deps with pak:

> pak::local_install_dev_deps()
✔ Loading metadata database ... done
Run `[rlang::last_trace()](vscode-file://vscode-app/Applications/Positron.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html#)` to see where the error occurred.                  
Error:
! ! error in pak subprocess
Caused by error: 
! Could not solve package dependencies:
* deps::/Users/jenny/tmp/impactr: Can't install dependency accdata
* accdata: Can't find package called accdata.

In cloud revdep checks, this particular package seems to just hang, causing the entire job to be stuck at 1 thing still in progress and n - 1 things being complete. Eventually, somewhere north of 2 hours, something appears to time out and you can run cloud_report(), which does not report anything about this problematic package.

I have a couple of wishes:

  • Can this doomed situation fail fast and be logged in the problems? Feels like it fits in the "failed to check" bucket.
  • Can we make it easier to find out which revdeps are still running? Part of what makes this situation tricky is that I can't see which package is the zombie. If I could, that unblocks me to do some local, artisanal troubleshooting. In this case, I have to wait 'til it's the only check still running, do cloud_report(), back out which packages have been checked, get the list of revdeps via revdepcheck::cran_revdeps("vroom"), then use setdiff() to figure out who's missing.
  • Given that this situation only generates a NOTE in CRAN's checks, should we be doing something different? Here's what CRAN shows for impactr at this moment:
Image

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions