Closed riosatbms closed 1 week ago
I observe the same behavior in our Posit Workbench. When I refresh the page, it usually will display. Sometimes I have to click it a time or two. Does refreshing work for you?
This happens in linux because it takes some time to spin up the server and is not possible to connect to it before it starts. I implemented a very unreliable wait of 1.5 seconds before trying to open the app in the viewer, but seems that it isn't enough. In #79 you can see a better option provided by @idavydov but I didn't include because no one else was reporting this issue.
Translating that code to httr2 for "R/addin_chatgpt.R" should fix it
The same "connection refused" mirror appears. Here the output for sessioninfo::session_info(pkgs = "gptstudio")
:
> sessioninfo::session_info(pkgs = "gptstudio")
─ Session info ────────────────────────────────────────────────────────────────────────────────────
setting value
version R version 4.3.2 (2023-10-31)
os Ubuntu 20.04.6 LTS
system x86_64, linux-gnu
ui RStudio
language (EN)
collate C.UTF-8
ctype C.UTF-8
tz UTC
date 2024-03-06
rstudio 2023.12.1+402.pro1 Ocean Storm (server)
pandoc NA
─ Packages ────────────────────────────────────────────────────────────────────────────────────────
package * version date (UTC) lib source
askpass 1.2.0 2023-09-03 [1] RSPM
assertthat 0.2.1 2019-03-21 [1] RSPM
base64enc 0.1-3 2015-07-28 [1] RSPM
bslib 0.6.1 2023-11-28 [1] RSPM
cachem 1.0.8 2023-05-01 [1] RSPM
cli 3.6.2 2023-12-11 [1] RSPM
colorspace 2.1-0 2023-01-23 [1] RSPM
commonmark 1.9.1 2024-01-30 [1] RSPM
crayon 1.5.2 2022-09-29 [1] RSPM
curl 5.2.1 2024-03-01 [1] RSPM
digest 0.6.34 2024-01-11 [1] RSPM
ellipsis 0.3.2 2021-04-29 [1] RSPM
evaluate 0.23 2023-11-01 [1] RSPM
fansi 1.0.6 2023-12-08 [1] RSPM
fastmap 1.1.1 2023-02-24 [1] RSPM
fontawesome 0.5.2 2023-08-19 [1] RSPM
fs 1.6.3 2023-07-20 [1] RSPM
glue 1.7.0 2024-01-09 [1] RSPM
gptstudio 0.3.1.9005 2024-03-06 [1] Github (MichelNivard/gptstudio@48872c7)
highr 0.10 2022-12-22 [1] RSPM
htmltools 0.5.7 2023-11-03 [1] RSPM
htmlwidgets 1.6.4 2023-12-06 [1] RSPM
httpuv 1.6.14 2024-01-26 [1] RSPM
httr 1.4.7 2023-08-15 [1] RSPM
httr2 1.0.0 2023-11-14 [1] RSPM
ids 1.0.1 2017-05-31 [1] RSPM
jquerylib 0.1.4 2021-04-26 [1] RSPM
jsonlite 1.8.8 2023-12-04 [1] RSPM
knitr 1.45 2023-10-30 [1] RSPM
later 1.3.2 2023-12-06 [1] RSPM
lifecycle 1.0.4 2023-11-07 [1] RSPM
magrittr 2.0.3 2022-03-30 [1] RSPM
memoise 2.0.1 2021-11-26 [1] RSPM
mime 0.12 2021-09-28 [1] RSPM
openssl 2.1.1 2023-09-25 [1] RSPM
pillar 1.9.0 2023-03-22 [1] RSPM
pkgconfig 2.0.3 2019-09-22 [1] RSPM
promises 1.2.1 2023-08-10 [1] RSPM
purrr 1.0.2 2023-08-10 [1] RSPM
R6 2.5.1 2021-08-19 [1] RSPM
rappdirs 0.3.3 2021-01-31 [1] RSPM
Rcpp 1.0.12 2024-01-09 [1] RSPM
rlang 1.1.3 2024-01-10 [1] RSPM
rmarkdown 2.25 2023-09-18 [1] RSPM
rstudioapi 0.15.0 2023-07-07 [1] RSPM
rvest 1.0.4 2024-02-12 [1] RSPM
sass 0.4.8 2023-12-06 [1] RSPM
selectr 0.4-2 2019-11-20 [1] RSPM
shiny 1.8.0 2023-11-17 [1] RSPM
shiny.i18n 0.3.0 2023-01-16 [1] RSPM
sourcetools 0.1.7-1 2023-02-01 [1] RSPM
SSEparser 0.1.0 2023-12-14 [1] RSPM
stringi 1.8.3 2023-12-11 [1] RSPM
stringr 1.5.1 2023-11-14 [1] RSPM
sys 3.4.2 2023-05-23 [1] RSPM
tibble 3.2.1 2023-03-20 [1] RSPM
tinytex 0.49 2023-11-22 [1] RSPM
utf8 1.2.4 2023-10-22 [1] RSPM
uuid 1.2-0 2024-01-14 [1] RSPM
vctrs 0.6.5 2023-12-01 [1] RSPM
waiter 0.2.5 2022-01-03 [1] RSPM
withr 3.0.0 2024-01-16 [1] RSPM
xfun 0.42 2024-02-08 [1] RSPM
xml2 1.3.6 2023-12-04 [1] RSPM
xtable 1.8-4 2019-04-21 [1] RSPM
yaml 2.3.8 2023-12-11 [1] RSPM
[1] /cloud/lib/x86_64-pc-linux-gnu-library/4.3
[2] /opt/R/4.3.2/lib/R/library
───────────────────────────────────────────────────────────────────────────────────────────────────
I just want to inform you guys that I'm looking into this. So far, I've been able to reproduce the problem using a docker image and it looks that the url translation required by rstudioapi::viewer()
is causing some problems. I'll keep you updated
This is a problem of RStudio Server instances. Rstudio Server requires the URL translation because it runs apps behind a proxy, meaning localhost:port is not directly possibly. So, we can`t just avoid the URL translation.
ATM I can't think of a programmatic way of detecting if the app is running. I though that if we make a http request for the translated URL we would get an error until the app server starts, so retrying periodically would detect when this happens. However, when ge make a get request for the translated URL we always (whether the app server is ready or not) get a response from the proxy (which I think is the rstudio server login page). rstudioapi::viewer()
somehow skips the auth page and is able to detect when the app server is not ready (connection refused) and when it is (the app shows normally).
So, ATM the easiest way of avoiding this bug would be to increase the hard coded waiting time or let users have a way of specifying how much waiting time they want. What do you think @JamesHWade ?
What about a check for the HTTP code? I think it fixed the error for me.
UPD: That's not a good suggestion, I think I didn't do that in my code.
I think what I ended up doing is the following:
host <- getOption("shiny.host", "127.0.0.1")
port <- random_port()
run_app_as_bg_job(
...,
host, port
)
wait_for_server(host, port)
open_bg_shinyapp(host, port)
wait_for_server <- function(host, port, timeout = 60) {
start_time <- as.numeric(Sys.time())
repeat {
r <- tryCatch(
httr::GET(glue::glue("http://{host}:{port}/")),
error = \(e) NULL
)
if (
as.numeric(Sys.time()) - start_time > timeout ||
(!is.null(r) && httr::status_code(r) < 300)
) {
break
}
Sys.sleep(0.2)
invisible(NULL)
}
}
open_bg_shinyapp <- function(host, port) {
url <- glue::glue("http://{host}:{port}")
parsed_url <- httr::parse_url(url)
if (parsed_url$hostname == "0.0.0.0") {
# rstudioapi::translateLocalUrl doesn't recognize 0.0.0.0 as a local URL
# we replace it with 127.0.0.1
parsed_url$hostname = "127.0.0.1"
url <- httr::build_url(parsed_url)
}
translated_url <- rstudioapi::translateLocalUrl(url, absolute = TRUE)
cli::cli_alert_info(
glue("Showing app in browser window, {translated_url}")
)
utils::browseURL(translated_url)
}
You could replace browseURL()
with viewer()
, I think. But I do not see a lot of advantages in using a builtin tiny viewer panel.
And I have some code to shut down a background job in case a tab is closed, that was quite robust for me.
What speaks against using a similar approach?
I'm open to either solution, @calderonsamuel and @idavydov. I also like having the background job shut down automatically. I'd preview to keep viewer()
for now since that preserves the apps current behavior. Having an option of browseURL()
could be a good compromise.
I almost always using the app in the viewer, but I also have large monitor.
Just to clarify, the following code was quite robust in detecting when the background shiny job has started.
wait_for_server(host, port)
open_bg_shinyapp(host, port)
As far as I remember, viewer()
vs browseURL()
both were working fine and I do not have any strong opinion here (I'm using a local fork anyway).
When working in Posit Workbench, starting the chat session via "Addins > ChatGPT" results in a "Connection Refused" message in the Viewer pane.
However, the using the
rstudioapi::viewer()
link provided in the supplied output correctly opens the chat window.Executing the rstudioapi::viewer("http://127.0.0.1:4441") on the console window it displays correctly on the viewer.
This behavior has been replicated in three different environments: our internal corporate environment, and two environments created in testing by Posit (cc @kmasiello)
The addin behaves as expected in the RStudio Desktop app.