Vignette building failure on linux and windows


I am using a R-CMD-check workflow based on the rlib/actions repo. The workflow worked on all 3 OSs (macOS, linux, windows), but has recently started failing on linux and windows. I have re-run the workflow from two weeks ago, which passed on all OSs, and it now fails (meaning that the same code that worked two weeks ago now fails).

The repo can be found on Github:

A link to the failed workflow is here:

The error is below:

* creating vignettes ... ERROR
Error: --- re-building 'large-files.Rmd' using rmarkdown
Quitting from lines 44-51 (large-files.Rmd) 
Error: Error: processing vignette 'large-files.Rmd' failed with diagnostics:
Names repair functions can't return `NA` values.
--- failed re-building 'large-files.Rmd'
--- re-building 'miplicorn.Rmd' using rmarkdown
Quitting from lines 29-31 (miplicorn.Rmd) 
Error: Error: processing vignette 'miplicorn.Rmd' failed with diagnostics:
Names repair functions can't return `NA` values.
--- failed re-building 'miplicorn.Rmd'
SUMMARY: processing the following files failed:
  'large-files.Rmd' 'miplicorn.Rmd'
Error: Error: Vignette re-building failed.
Execution halted
Error: Error in proc$get_built_file() : Build process failed
Calls: <Anonymous> ... build_package -> with_envvar -> force -> <Anonymous>
Execution halted
Error: Process completed with exit code 1.

I have been unable to replicate the error on macOS and have been unable to find any solutions online. Any help explaining why my code now fails would be greatly appreciated!


:wave: @arisp99, here are some elements that might be helpful. Good luck!

I can reproduce the error

> read_file(cov_file)
  Names repair functions can't return `NA` values.
Caused by error: 
  Names repair functions can't return `NA` values.
  1. miplicorn::read_file(cov_file)
  4. vroom `<fn>`(`<col_spec>`, 123L, `<chr>`, `<quos>`, "unique")
  6. tidyselect::vars_select(names(spec$cols), !!!col_select, .strict = FALSE)
  7. tidyselect:::eval_select_impl(...)
 15. tidyselect:::vars_select_eval(...)
 16. tidyselect:::ensure_named(pos, vars, uniquely_named, allow_rename)
 17. vctrs::vec_as_names(names(pos), repair = "check_unique")
 18. vctrs `<fn>`()
 19. vctrs:::validate_unique(names = names, arg = arg)
 20. vctrs:::validate_minimal_names(names, n)

I am using Ubuntu but am not sure it's a specific OS thing, it's probably rather due to versions of some of the dependencies (e.g. vroom). I might be wrong, of course. A good tip by @krlmlr:

PSA: Record your sessioninfo::session_info() or sessioninfo::package_info() for #rstats environments where you don't control for package versions. It helps a lot when things start to fail for no apparent reason.

You could switch from your remotes-based GHA workflow to a pak-based GHA workflow actions/examples at old · r-lib/actions · GitHub as it should by default include session info in the log see e.g.

If you compare versions between the failing checks and your local environment, it might help? See a similar issue (same error message, but probably different exact cause).

In practice in your code

  # Read in entire data set but select only columns we are interested in
  data <- vroom::vroom(
    file = .file,
    col_names = FALSE,
    col_select = c(1, col_select),
    show_col_types = FALSE

are the lines failing. They do not fail if I set col_names to TRUE but I have no idea what I'm doing. I'd recommend checking your assumptions about the data at that stage, and maybe setting col_names to TRUE or changing the .name_repair argument in vroom::vroom (contrary to me you'll know what you are doing as you know what the data manipulation is supposed to do).

Thanks for the suggestions @maelle !

After changing the GHA workflow to use {pak} instead of {remotes}, I compared my local and remote package versions and found one difference. Updating the package on my end changed nothing... Likely, this means that the error is not due to package versions, but that was a good idea!

While I am still unable to reproduce the error on macOS (either locally or with GHA), I believe I have made some progress debugging. I now believe the error lies with {vroom} and have posted an issue on the Github repo (

To summarize the issue, I made a small package and attempted to read a file using {vroom}. When I set col_names = FALSE the same error appeared on GHA. It passed on macOS but failed on Windows/Ubuntu.

A link to the small (and reproducible package) is here: While I think {vroom}is causing the issue, I may still be doing something wrong in my workflow, or there may be some other explanation.

Nevertheless thanks for the input!

1 Like

This has now been resolved by the authors of {vroom}.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.