Fail to connect to RSC after unversionning pins on rstudio connect board

[Ludo-vic-D]

Hi all, Got an issue on Rsconnect :

• first deploy a .rmd to pin a VERSIONNED object on rsconnect board
• ok for pin read into shiny app
• redeploy the .rmd to make non versionned pin --> get classical error about delete a pin to un-version it
• deleting pins from rsconnect
• redeploy the .rmd --> ok for un-versionned pin
• but now there is an issue on shiny app :

Connecting to RSC 1.8.6.2 at https://rstudioconnect.********** x Failed to connect to RSC; using cached version

with simple .rmd // shiny app as below, the pin get read and output is ok but with complexe app i have more issue with partialy non aviable data (same data, sometimes ok for visualisation, sometimes no with this error : Error in rsc_check_status: Not Found (HTTP 404) )

Precision : shiny app hosted on rsconnect server works fine ; shiny app launched on ide --> issuer

solution find : make pin with another name

have fun guys!

here the .rmd code :

title: "testpins" output: html_document

knitr::opts_chunk$set(echo = TRUE)

library(pins)
library(httr)
 httr::set_config(httr::config(ssl_verifypeer = FALSE, ssl_verifyhost = FALSE))

 RSC_board_Capsules<-board_rsconnect(auth = "envvar",
                                     server = "https://rstudioconnect**************",
                                     key = "********************")

pin_write(board = RSC_board_Capsules,x = head(iris),name = "irisssssss",versioned = F)

here the simple shiny app :

library(shiny)
library(pins)
library(httr)
httr::set_config(httr::config(ssl_verifypeer = FALSE, ssl_verifyhost = FALSE))

RSC_board_Capsules<-board_rsconnect(auth = "envvar",
                                    server = "https://rstudioconnect.**********m",
                                    key = "*****************")

irissss<-pin_reactive_read(RSC_board_Capsules,  "ludovic/irisssssss")

ui <- fluidPage(
    # Application title
    titlePanel("Old Faithful Geyser Data"),
        mainPanel(
           tableOutput("distPlot")
        )
)
server <- function(input, output) {
    output$distPlot <- renderTable({
        irissss()
    })
}

# Run the application 
shinyApp(ui = ui, server = server)

rsconnect build : V1.8.6.2-0-gbce6f036c1

R version 3.6.3 (2020-02-29) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 19042)

Matrix products: default

locale: [1] LC_COLLATE=French_France.1252 LC_CTYPE=French_France.1252 LC_MONETARY=French_France.1252 LC_NUMERIC=C
[5] LC_TIME=French_France.1252

attached base packages: [1] stats graphics grDevices utils datasets methods base

other attached packages: [1] shinyjs_2.1.0 httr_1.4.2 pins_1.0.1 pryr_0.1.4 config_0.3.1 stringi_1.6.1
[7] gsubfn_0.7 proto_1.0.0 data.table_1.14.0 fasttime_1.0-2 tibble_3.1.1 purrr_0.3.4
[13] tidyr_1.1.3 DT_0.21 magrittr_2.0.1 tm_0.7-8 NLP_0.2-1 stringr_1.4.0
[19] plotly_4.10.0 ggplot2_3.3.5 shinydashboard_0.7.2 dplyr_1.0.6 plyr_1.8.6 shiny_1.7.1

loaded via a namespace (and not attached): [1] sass_0.4.0 jsonlite_1.7.2 viridisLite_0.4.0 bslib_0.3.1 assertthat_0.2.1 askpass_1.1 conflicted_1.1.0 [8] yaml_2.2.1 slam_0.1-48 pillar_1.7.0 glue_1.6.2 digest_0.6.27 promises_1.2.0.1 colorspace_2.0-1 [15] htmltools_0.5.2 httpuv_1.6.1 pkgconfig_2.0.3 xtable_1.8-4 scales_1.1.1 fontawesome_0.2.2 later_1.2.0
[22] openssl_1.4.4 tictoc_1.0.1 generics_0.1.2 ellipsis_0.3.2 cachem_1.0.4 withr_2.4.3 lazyeval_0.2.2
[29] cli_3.2.0 crayon_1.5.0 mime_0.10 evaluate_0.15 memoise_2.0.1 fs_1.5.0 fansi_0.4.2
[36] xml2_1.3.2 rsconnect_0.8.25 tools_3.6.3 hms_1.1.1 lifecycle_1.0.1 munsell_0.5.0 compiler_3.6.3
[43] jquerylib_0.1.4 tinytex_0.37 rlang_0.4.11 grid_3.6.3 rstudioapi_0.13 rappdirs_0.3.3 htmlwidgets_1.5.4 [50] crosstalk_1.2.0 rmarkdown_2.11 tcltk_3.6.3 gtable_0.3.0 codetools_0.2-16 DBI_1.1.2 curl_4.3.1
[57] R6_2.5.1 lubridate_1.7.10 knitr_1.37 fastmap_1.1.0 utf8_1.2.1 readr_1.4.0 parallel_3.6.3
[64] Rcpp_1.0.6 vctrs_0.3.8 tidyselect_1.1.1 xfun_0.29

[machow]

Just a quick thought--based on what sounds like this workflow:

• creating an unversioned pin
• accessing that pin via a shiny app (using pin_reactive_read)
• periodically updating the unversioned pin

I wonder if the issue might be a race condition between pin_reactive_read and someone writing an update to the pin:

1. pin_reactive_read runs pin_meta, and pin_read
2. pin_meta or pin_read gets an underlying version guid
3. in the meantime, pin_write deletes the old version
4. by the time something from (2) goes to fetch the content based on guid, it doesn't exist anymore

[Ludo-vic-D]

Just a quick thought--based on what sounds like this workflow:

• creating an unversioned pin
• accessing that pin via a shiny app (using pin_reactive_read)
• periodically updating the unversioned pin

I wonder if the issue might be a race condition between pin_reactive_read and someone writing an update to the pin:

1. pin_reactive_read runs pin_meta, and pin_read
2. pin_meta or pin_read gets an underlying version guid
3. in the meantime, pin_write deletes the old version
4. by the time something from (2) goes to fetch the content based on guid, it doesn't exist anymore

the issue only appears when i first create a versionned pin ; then delete pin and recreate pin with same name but unversionned. works fine with new versionned pin works fine with new unversionned pin works fine with a new unversionned pin replaced by versionned pin error with new versionned pin replaced by unversionned.

you can try it with .rmd and shiny app exemple

[ntentes]

Just a quick outline on how we got this to work:

1. Open an R session and run pins::cache_info() to figure out where your cache is stored (the first line of output offers the path to your pin cache).
2. If you are comfortable emptying your cache for all pins, run pins::cache_prune(days = 0), but if you only want your current problem pins to work and not change anything else, don't run that.
3. Go into your cache folders and find content-cache.yml (I had two different folders with this file).
4. Remove the references to the old pins in those YAML files and save. The references will look like:

tino/pin1:
  guid: guid1
  url: https://***/content/guid1/
tino/pin2:
  guid: guid2
  url: https://***/content/guid2/
tino/pin3:
  guid: guid3
  url: https://***/content/guid3/

You can empty the file completely if you like. Don't delete other folders or you risk removing your local pin board.

You shouldn't have this issue when reading the pins from your board after the steps above.

[machow]

Ah, thanks! It appears the issue is caused by...

• when a pin is deleted, it's removed from content-cache.yml on the deleter's machine
• it is not deleted from any other machine with a content-cache.yml

So when a pin is created with the same (deleted) <user>/<content_name>, this happens...

• when the "other" machine tries to read the pin (e.g. michael/some_pin), it looks in content-cache.yml to find the pin's content guid
• It finds the old guid
• It tries to read that content, but since it's deleted you get the error (via rsc_content_version_cached).

I'm not sure the fix. It seems like the content-cache.yml mechanism should be removed (but also drilled into beforehand to understand what it is speeding up)

[juliasilge]

In #667 we changed these caches over to use environments (instead of files on disk). This means that:

• caches will not persist between sessions
• caches will only get into a broken state if a big change is made with the server while a user is working with pins from R
• caches can be fixed by restarting R
• the first time functions are called they will be slow, but subsequent calls will have the same benefits of caching as we had originally

Thanks again for the report! 🙌

[github-actions[bot]]

This issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with a reprex: https://reprex.tidyverse.org) and link to this issue.