Viewer Connection Refused" when starting chat session from add in #179
Comments
|
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 |
|
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 |
|
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). 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 ? |
|
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 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 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, |
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.
The text was updated successfully, but these errors were encountered: