quarto_preview("script.R") gives 404 on "/"

[aronatkins]

Given a Quarto project with a trivial _quarto.yml and a script.R, calling quarto_preview() against that script results in a 404 to the console and "Not Found" in the RStudio viewer pane.

remotes::install_github("quarto-dev/quarto-r")

...
Watching files for changes
Browse at http://localhost:6730/script.html
Stop the preview with quarto_preview_stop()
GET: / (404: Not Found)

The _quarto.yml:

project:
    title: "running a script"

The script.R:

#' ---
#' title: Palmer Penguins
#' ---

The http://localhost:6730/script.html URL printed by Quarto is correct, but RStudio visits http://localhost:6730/.

quarto-r: 1.4
quarto: 1.4.551
RStudio: 2024.04.0-daily+635

Filing here for tracking, but it may be a Quarto or RStudio issue.

Similar to rstudio/rstudio#11163

[aronatkins]

Workaround: Run preview from the terminal, which opens a browser tab (not the RStudio viewer pane):

quarto preview script.R

[cderv]

calling quarto_preview() against that script results in a 404 to the console and "Not Found" in the RStudio viewer pane.

This was because quarto_preview() takes over quarto preview browsing by setting --no-browse, to use RStudio viewer when in IDE.

It will now parse the log message to use the same URL as quarto preview would have opened.

[idavydov]

I'm on quarto 1.4.4 and somehow I am still getting this error:

> options(browser=\(url) cat(paste0(url, "\n")))
> quarto::quarto_preview("report.qmd")


processing file: report.qmd
1/29                   
2/29 [unnamed-chunk-1] 
3/29                   
4/29 [unnamed-chunk-2] 
5/29                   
6/29 [unnamed-chunk-3] 
7/29                   
8/29 [unnamed-chunk-4] 
9/29                   
10/29 [unnamed-chunk-5] 
11/29                   
12/29 [unnamed-chunk-6] 
13/29                   
14/29 [unnamed-chunk-7] 
15/29                   
16/29 [unnamed-chunk-8] 
17/29                   
18/29 [unnamed-chunk-9] 
19/29                   
20/29 [unnamed-chunk-10]
21/29                   
22/29 [unnamed-chunk-11]
23/29                   
24/29 [unnamed-chunk-12]
25/29                   
26/29 [unnamed-chunk-13]
27/29                   
28/29 [unnamed-chunk-14]
29/29                   
output file: report.knit.md

pandoc 
  to: revealjs
  output-file: report.html
  standalone: true
  wrap: none
  default-image-extension: png
  html-math-method:
    method: mathjax
    url: >-
      https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=T
eX-AMS_HTML-full
  slide-level: 2
  
metadata
  link-citations: true
  width: 1050
  height: 700
  margin: 0.1
  center: false
  navigationMode: linear
  controlsLayout: edges
  controlsTutorial: false
  hash: true
  history: true
  hashOneBasedIndex: false
  fragmentInURL: false
  transition: none
  backgroundTransition: none
  pdfSeparateFragments: false
  lang: en
  auto-stretch: true
  editor: visual
  ...
  date: today
  
Output created: report.html

Watching files for changes
Browse at http://localhost:3345/report.html
Stop the preview with quarto_preview_stop()http://localhost:3345
> 

[cderv]

@idavydov The error was

GET: / (404: Not Found)

Related to serving R files rendered with Quarto.

From your shared code

• I don't see the error if your log
• You are running quarto_preview on a .qmd file.

So if you have an issue, this is probably different than this one.

Please do open a new issue, and share a reproducible example, or all necessary information to help me look at it.

Thanks.

[idavydov]

Hi @cderv ,

I'm happy to open a new issue, but are you positive it's a separate one?

The only difference I see is that @aronatkins is using an R script, while I am using qmd.

• Both @aronatkins and I are running quarto_preview()
• quarto_preview() calls a browser on http://localhost:<port>/ instead of http://localhost:<port>/report.html
• I assume in both cases quarto_preview() should extract the correct URL from the logs of quarto.

The only reason there's no 404 in the logs is that I overrides the options(browser=...) to see which URL is passed to browseURL(), as far as I understand at least.

[cderv]

I'm happy to open a new issue, but are you positive it's a separate one?

It could be or it could not, but having new issue helps us investigate in a clean way, and without creating too much notification to users of this closes threads that may not want to be notified about new things. (please don't ping users too aggressively unless necessary). It happens that past fixed don't cover all cases, but this is not helpful to comments and discuss in an old thread.

Anyway, I created the new issue myself then so we can keep the discussion.