Failure to build chapter doesn't immediately stop book from building

[hadley]

Instead, it fails later when assembling the entire book. For example, in Mastering Shiny if the scaling-test.Rmd chapter has an error, the build process completes but gives a less informative error:

Error in file(con, "r") : cannot open the connection
Calls: <Anonymous> ... mapply -> <Anonymous> -> read_utf8 -> readLines -> file
In addition: Warning message:
In file(con, "r") :
  cannot open file 'scaling-testing.md': No such file or directory
Warning message:
In file.rename(unlist(meta)[move], files_md[move]) :
  cannot rename file 'scaling-testing.md' to '_book/scaling-testing.md', reason 'No such file or directory'

And then to find the source of the error I have to scroll up through a very large amount of output to find:

label: unnamed-chunk-2
Quitting from lines 11-12 (scaling-testing.Rmd) 
Error in eval(expr, envir, enclos) : !
Calls: local ... handle -> withCallingHandlers -> withVisible -> eval -> eval

It would be better to fail earlier.

[hadley]

Just to give you a sense of how annoying this is. Here's a link to a ~3,000 line log file I need to scroll through to figure out why the book failed to build: https://gist.github.com/hadley/04f96d091364fdd198031e078cdb1b1e

[cderv]

When I try to compile the mastering shiny book, I encounter some errors and it stops the rendering process at basic.Rmd chapter. See here: https://gist.github.com/cderv/fa5c3a105a90a783a5e4defadfcb3499

If I try with bookdown demo book by introducing an error in 02-literature.Rmd for example, it will stop the rendering of the book at this chapter without processing any further.

So it seems it is not something generic about bookdown, and could be specific to a setup.

I was wondering if this was interactive vs non-interactive but running

Rscript.exe -e "bookdown::render_book('index.Rmd', 'bookdown::gitbook')"

in terminal also throws the error at the chapter rendering, and do not build the whole book.

Did I miss anything ? Is this is happening for you no matter the book ?

[hadley]

I normally run the book via RStudio, which generates rmarkdown::render_site(output_format = 'bookdown::pdf_book', encoding = 'UTF-8'). But even if I run bookdown::render_book("index.Rmd", "bookdown::gitbook"), it still continues when I introduce an error in an early chapter.

[master] > packageVersion("bookdown")
[1] ‘0.21’
[master] > packageVersion("rmarkdown")
[1] ‘2.4.4’
[master] > packageVersion("knitr")
[1] ‘1.30’

I have the same problem with R4DS.

[cderv]

I can't reproduce this unfortunatly - I tried on Windows and on Ubuntu with the Mastering Shiny book by cloning the repo. Everytime I have an error within one the file, it stops the rendering at that file. I tried with render_book and with render_site
It does not process the all book. I don't have a Mac to try but I don't see why this would be OS related.

Steps I did

• I clone the mastering shiny book
• I installed all the dependencies
• I added a chunk in introduction.Rmd under ## What is Shiny ?

```{r}
stop('Creating an error to test issue #920')
```

• I ran rmarkdown::render_site(output_format = 'bookdown::pdf_book', encoding = 'UTF-8')

here is the whole result I got in the console

> rmarkdown::render_site(output_format = 'bookdown::pdf_book', encoding = 'UTF-8')


processing file: index.Rmd
  |......................................................................| 100%
   inline R code fragments


output file: index.knit.md



processing file: introduction.Rmd
  |....                                                                  |   6%
  ordinary text without R code

  |........                                                              |  11%
label: unnamed-chunk-1 (with options) 
List of 1
 $ include: logi FALSE

  |............                                                          |  17%
  ordinary text without R code

  |................                                                      |  22%
label: unnamed-chunk-2
Quitting from lines 10-11 (introduction.Rmd) 
Error in eval(expr, envir, enclos) : Creating an error to test issue #920
Calls: local ... handle -> withCallingHandlers -> withVisible -> eval -> eval

Execution halted
Error in Rscript_render(f, render_args, render_meta, add1, add2) : 
  Failed to compile introduction.Rmd

Unfortunatly, without being able to reproduce, I will have a hard time looking further - I wonder why I don't encounter this behavior if you have it in two books.

I have this

packageVersion("bookdown")
#> [1] '0.21'
packageVersion("rmarkdown")
#> [1] '2.4.6'
packageVersion("knitr")
#> [1] '1.30'

Do you have special config regarding error in a Rprofile or else ? Could we try to reproduce this in an example using the bookdown-demo example that is simple book ? That may be easier to isolate the issue.

[hadley]

That was useful, thanks! It also failed for me when run with R --vanilla. A bit of experimentation with my .Rprofile found that the problem was:

options(error = rlang::entrace)

I use this to give better tracebacks for base errors, so it would be nice to figure out why this breaks knitr. I'm happy to look into it if you can point me to the code responsible for generating the "Execution halted" error.

[hadley]

I wonder if the root cause is using system() for running code in another process — in callr, I think we automatically bubble up the error message into the parent process so you can access the full trace back.

[cderv]

Thanks, I'll investigate further with that option activated. I'll get back to you.

[cderv]

Regarding the Execution halted, I believe this comes from R here:
https://github.com/wch/r-source/blob/a48c6bea1353ce9b79beee0022a19ceeae822162/src/main/main.c#L342

Bookdown call Rscript using system2() to run an R script render_one.R that will call the rmarkdown::render(). Traceback is

> traceback()
8: stop("Failed to compile ", file)
7: Rscript_render(f, render_args, render_meta, add1, add2)
6: render_new_session(files, main, config, output_format, clean, 
       envir, ...)
5: render_book("index.Rmd", output_format = output_format, envir = envir)
4: render_book_script(output_format, envir, quiet)
3: in_dir(input, render_book_script(output_format, envir, quiet))
2: generator$render(input_file = input_file, output_format = output_format, 
       envir = envir, quiet = quiet)
1: rmarkdown::render_site(output_format = "bookdown::pdf_book", 
       encoding = "UTF-8")

That would mean the use of rlang::entrace prevent the error to halt the execution of Rscript and from bookdown point of view the Rscript_render call did not fail.

Could this be the source of the error ?

[yihui]

I wonder if the root cause is using system() for running code in another process

It is indeed a system() call, and it should thrown an error if the exit status is non-zero. My current guess is that your setting affected the exit status, and it became 0 even if there was an error. I'm not familiar with rlang::entrace, so I'm not sure.

[cderv]

I can now reproduce by using options(error = rlang::entrace) if I put it in my .Rprofile. That is because bookdown calls Rscript that will load the site files.

I think we narrowed down the issue now. @hadley you know better rlang::entrace, do you see why it happens this way ?

[cderv]

And here is the reprex of the underlying issue in bookdown

res <- xfun::Rscript(
  shQuote(c("--vanilla", "-e", 'stop("An error")'))
)
res
#> [1] 1
res <- xfun::Rscript(
  shQuote(c("--vanilla", "-e", 'options(error = rlang::entrace); stop("An error")'))
)
res
#> [1] 0

^{Created on 2020-10-19 by the reprex package (v0.3.0.9001)}

First case throws 1 as a result, hence bookdown knows there is an error. Second throws 0 as a result, so bookdown does not know there is an error.

[cderv]

Last precision: this is not an issue with only system() or system2(). Here is what I got if I use callr::rscript which uses processx::run

temp_r <- tempfile()
xfun::write_utf8(c('stop("An error")'), temp_r)

# will error
res <- callr::rscript(temp_r, "--vanilla")
#> Error: An error
#> Execution halted
#> Error in (function (command = NULL, args = character(), error_on_status = TRUE, : System command 'Rscript' failed, exit status: 1, stdout & stderr were printed

# res was not created
res
#> Error in eval(expr, envir, enclos): object 'res' not found

temp_r <- tempfile()
xfun::write_utf8(c('options(error = rlang::entrace)', 'stop("An error")'), temp_r)
# will not error on our console
res <- callr::rscript(temp_r, "--vanilla")
#> Error: An error
str(res)
#> List of 5
#>  $ status : int 0
#>  $ stdout : chr ""
#>  $ stderr : chr "Error: An error\n"
#>  $ timeout: logi FALSE
#>  $ command: chr [1:3] "/usr/lib/R/bin/Rscript" "/tmp/RtmpV57zmp/file24f25c9e5c96" "--vanilla"

^{Created on 2020-10-19 by the reprex package (v0.3.0.9001)}

First case without rlang, rscript is correctly throwing an error that callr throws to us. Second case, there is no error thrown in R but Rscript was indeed with an error.

[cderv]

Same in terminal also in Ubuntu

$ /usr/lib/R/bin/Rscript --vanilla  -e "stop('An error')"
Error: An error
Execution halted
$ /usr/lib/R/bin/Rscript --vanilla  -e "options(error = rlang::entrace);stop('An error')"
Error: An error

[hadley]

Yeah, it's ok with callr::r() which is why we haven't noticed this before:

callr::r(function() {
  options(error = rlang::entrace)
  stop("Hi!")
})
#> Error: callr subprocess failed: Hi!

^{Created on 2020-10-19 by the reprex package (v0.3.0.9001)}

I'll figure out what's going on on the entrace side.

[hadley]

(If you run callr::r() interactively, you'll notice that it allows you to get at the traceback of the failure in the child process)

[cderv]

Oh I did not know that. That is insteresting ! It is clearly useful for debugging. Thanks for sharing.

[lionel-]

Unlike calling handlers, options(error = ) handlers do not have a concept of declining to handle an error. So R sets the status to 0 when such a handler is set.

rlang::entrace() now removes itself from options(error = ) in non-interactive sessions to work around this.

[cderv]

Thanks @lionel- ! I confirm this is now working from bookdown.
Thanks for the report @hadley.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.