Skip to content
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

future_promise called in a shiny renderPlot call triggers new plot device creation locally, error in remote server. #69

Open
bakaburg1 opened this issue May 27, 2021 · 0 comments

Comments

@bakaburg1
Copy link

bakaburg1 commented May 27, 2021

Hello, we are trying to implement future_promise in our shiny app and we're facing an odd problem. Please refer to the attached file (in txt format since github doesn't like .r files).

test.txt

This test app tries to plot some graph after having triggered a future_promise. There 3 relevant blocks in the code (the fourth is just a control scenario).

On my local machine (MacOs) running this app opens spontaneously an extra RStudio/Quartz session, due to the block in lines 64-68 that runs the future_fun() function (second code block). On our remote server instead, this triggers a full error: "Unhandled promise error: cannot open file 'Rplots.pdf'".
The third block also triggers the same behaviour (you need to comment out the second block to observe it). The difference is that the future_fun() is run in an eventReactive() and its output is then called in a renderPlot() call.

This happens only the first time the app is run, and you need to restart the R session to reproduce it. BTW, force closing the extra RStudio session crashes also the main session, so it's like a restart...

The code in block 1 instead runs fine (you need to comment out block 2 and 3 first), because future_fun() updates a reactiveVal() whose change then triggers the plotting.

But the most interesting piece is that one uncomments Cairo(file='/dev/null') on line 26 the strange behaviour and errors go away. If you uncomment the Cairo call, run the app (without errors) and then comment it again the errors do not appear anyway. So everything happens in some initialization phase.

We couldn't find any reference to this behaviour and it took us a while to reconstruct it. It is especially annoying serverside since it triggers a full error not just an empty plot.

Local session:

> sessionInfo()
R version 4.0.5 (2021-03-31)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Big Sur 10.16

Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

other attached packages:
[1] Cairo_1.5-12.2   ggplot2_3.3.3    dplyr_1.0.6      promises_1.2.0.1 future_1.21.0   
[6] shiny_1.6.0     

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.6        jquerylib_0.1.3   bslib_0.2.4       compiler_4.0.5    pillar_1.6.1     
 [6] later_1.2.0       tools_4.0.5       digest_0.6.27     jsonlite_1.7.2    gtable_0.3.0     
[11] lifecycle_1.0.0   tibble_3.1.2      pkgconfig_2.0.3   rlang_0.4.11      DBI_1.1.1        
[16] yaml_2.2.1        parallel_4.0.5    fastmap_1.1.0     withr_2.4.1       systemfonts_1.0.0
[21] sass_0.3.1        generics_0.1.0    vctrs_0.3.8       globals_0.14.0    grid_4.0.5       
[26] tidyselect_1.1.1  glue_1.4.2        listenv_0.8.0     R6_2.5.0          textshaping_0.2.1
[31] fansi_0.4.2       parallelly_1.23.0 farver_2.1.0      purrr_0.3.4       magrittr_2.0.1   
[36] scales_1.1.1      codetools_0.2-18  ellipsis_0.3.2    htmltools_0.5.1.1 rsconnect_0.8.16 
[41] assertthat_0.2.1  colorspace_2.0-0  mime_0.10         xtable_1.8-4      httpuv_1.6.0     
[46] ragg_0.4.1        labeling_0.4.2    utf8_1.2.1        munsell_0.5.0     cachem_1.0.4     
[51] crayon_1.4.1 

Server side:

> sessionInfo()
R version 4.0.5 (2021-03-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.2 LTS
Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
locale:
 [1] LC_CTYPE=C.UTF-8       LC_NUMERIC=C           LC_TIME=C.UTF-8       
 [4] LC_COLLATE=C.UTF-8     LC_MONETARY=C.UTF-8    LC_MESSAGES=C.UTF-8   
 [7] LC_PAPER=C.UTF-8       LC_NAME=C              LC_ADDRESS=C          
[10] LC_TELEPHONE=C         LC_MEASUREMENT=C.UTF-8 LC_IDENTIFICATION=C   
attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     
other attached packages:
[1] ggplot2_3.3.3    png_0.1-7        Cairo_1.5-12.2   promises_1.2.0.1
[5] future_1.21.0    shiny_1.6.0     
loaded via a namespace (and not attached):
 [1] Rcpp_1.0.6        jquerylib_0.1.3   bslib_0.2.4       compiler_4.0.5   
 [5] pillar_1.5.1      later_1.1.0.1     tools_4.0.5       digest_0.6.27    
 [9] jsonlite_1.7.2    lifecycle_1.0.0   tibble_3.1.0      gtable_0.3.0     
[13] pkgconfig_2.0.3   rlang_0.4.10      DBI_1.1.1         parallel_4.0.5   
[17] fastmap_1.1.0     dplyr_1.0.5       withr_2.4.1       sass_0.3.1       
[21] generics_0.1.0    vctrs_0.3.6       globals_0.14.0    tidyselect_1.1.0 
[25] grid_4.0.5        glue_1.4.2        listenv_0.8.0     R6_2.5.0         
[29] fansi_0.4.2       parallelly_1.25.0 purrr_0.3.4       magrittr_2.0.1   
[33] scales_1.1.1      codetools_0.2-18  ellipsis_0.3.1    htmltools_0.5.1.1
[37] assertthat_0.2.1  mime_0.10         xtable_1.8-4      colorspace_2.0-0 
[41] httpuv_1.5.5      utf8_1.2.1        munsell_0.5.0     cachem_1.0.4     
[45] crayon_1.4.1   
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant