Many people and package maintainers use isAvailable without wrapping it around try-catch, thinking the function never errors out. However, I found myself in a weird situation where isAvailable errors out if the child processes mess up the system environments.
This issue happens when a job (child 1) wipe out the system environment but launches another rstudio job (child of child 1) from within...
tfile <- tempfile()
writeLines(
r'(
Sys.unsetenv("RSTUDIOAPI_IPC_REQUESTS_FILE")
Sys.unsetenv("RSTUDIOAPI_IPC_RESPONSE_FILE")
Sys.unsetenv("RSTUDIOAPI_IPC_SHARED_SECRET")
Sys.setenv("RSTUDIO_WORKBENCH_JOB" = "1")
print(rstudioapi::isJob())
print(rstudioapi::isAvailable(child_ok = TRUE))
)', con = tfile
)
source(tfile)
#> [1] TRUE
#> Error in callRemote(sys.call(), parent.frame()) :
#> internal error: callRemote() called without remote connection
rstudioapi::jobRunScript(tfile)
#> Error in callRemote(sys.call(), parent.frame()) :
#> internal error: callRemote() called without remote connection
Would it be OK to add an additional argument to isAvailable that if the function errors out, show a warning instead of erroring out?
Many people and package maintainers use
isAvailablewithout wrapping it around try-catch, thinking the function never errors out. However, I found myself in a weird situation whereisAvailableerrors out if the child processes mess up the system environments.This issue happens when a job (child 1) wipe out the system environment but launches another rstudio job (child of child 1) from within...
Would it be OK to add an additional argument to
isAvailablethat if the function errors out, show a warning instead of erroring out?