-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
![image](https://private-user-images.githubusercontent.com/11391516/307058452-b6844f90-f0be-441a-91ae-6f1b9ec5f599.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQ1NDI5NzgsIm5iZiI6MTcyNDU0MjY3OCwicGF0aCI6Ii8xMTM5MTUxNi8zMDcwNTg0NTItYjY4NDRmOTAtZjBiZS00NDFhLTkxYWUtNmYxYjllYzVmNTk5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODI0VDIzMzc1OFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTExNTM2ODYzYjA0NjU3ZmU5ZWNmNThkZGQ3OGJmYTI2ZTgzNTU3YjlkYjZkYmIzNDhmNTIzM2NkYjgwOTY5NzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.eh6fUzeJwxdsdSkakryU5Mp63spGoWvlc-oT2EcOVBQ)
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: