rstudio / plumber

Turn your R code into a web API.
https://www.rplumber.io
Other
1.39k stars 256 forks source link

Tests run for ever on i386 #832

Open nileshpatra opened 3 years ago

nileshpatra commented 3 years ago

Hi,

Thanks for your work on plumber. On i386, plumber version 1.1.0 (latest one) tests seem to keep running forever. Eventually, they time out and exits with a failure on Debian CI. Full log can be found here

I confirm that I can also reproduce it locally in an i386 chroot, and hence this failure is not just specific to the CI machine. One notable thing is that this problem does not exist in version 1.0.0 as could be seen here and this is likely a regression with the new one.

Please consider to fix this, I'd really appreciate your help. Thanks again!

meztez commented 3 years ago

@nileshpatra Would mind providing some instructions on how to reproduce this? I'm not familiar with this particular tool chain.

nileshpatra commented 3 years ago

@meztez sure, you could

a) create a i386 chroot via debootstrap something like: $ debootstrap --arch i386 sid $ http://deb.debian.org/debian/ chroot to that volume, and test the way you'd usually do with testthat

b) Spin up a docker container with a Dockerfile like:

FROM --platform=i386 debian:unstable
RUN apt-get -y update
RUN apt-get install r-base
RUN R -e "install.packages 
...... so on ..... and then trigger tests with testthat

Apologies, but I do not have the commands handy, but this should give an idea.

The way I am testing it from a Debian package is like this exactly though you might not need to do this, but still for ref (since these are un-necessary extra steps, and simply doing it with the way upstream tests are run would be easy to test):

$ sudo chroot <chroot-path>
# cd /root/
# apt-get install r-cran-plumber r-cran-testthat r-cran-pki r-cran-rmarkdown r-cran-htmlwidgets r-cran-readr
# apt-get source r-cran-plumber
# cd r-cran-plumber-1.1.0/
# bash ./debian/tests/run-unit-test

Please do let me know if you need more information.

meztez commented 3 years ago

@nileshpatra I was able to track down the hang to https://github.com/rstudio/plumber/blob/06e46f3ff5119e5f1cb8af29ef49aecb3cbb932a/tests/testthat/test-plumber-run.R#L4

If you remove test-plumber-run.R, it should not hang. I still have to find out why later is hanging for that long.

if you start R manually then run, it won't hang

library(testthat)
library(plumber)
test_check()

But using the debian run-unit-test script will hang.

nileshpatra commented 3 years ago

@nileshpatra I was able to track down the hang to https://github.com/rstudio/plumber/blob/06e46f3ff5119e5f1cb8af29ef49aecb3cbb932a/tests/testthat/test-plumber-run.R#L4 If you remove test-plumber-run.R, it should not hang. I still have to find out why later is hanging for that long.

@meztez thanks for the heads up!

if you start R manually then run, it won't hang library(testthat) library(plumber) test_check()

I had cloned this upstream repo, switched to tag 1.1.0, and it was still hanging for me -- weird. Would you mind providing the instructions on how you ran this one exactly?

But using the debian run-unit-test script will hang.

The script is essentially doing the exact same thing as running it with R, i.e. copying the tests directory and running testthat.R, which does the same set of operations, as running manually. I'm not very sure why this might not work, if the former did for you. Instructions on how you reproduced this would be appreciated.

But thanks a lot for the heads up, I could exclude this failing test for now in i386 and upload.

meztez commented 3 years ago

@nileshpatra

from a fresh bullseye.

sudo apt update
sudo apt install debootstrap
sudo debootstrap --arch i386 sid $<your_chroot>
sudo chroot <chroot-path>
cd /root/
apt-get install r-cran-plumber r-cran-testthat r-cran-pki r-cran-rmarkdown r-cran-htmlwidgets r-cran-readr
apt-get source r-cran-plumber
cd r-cran-plumber-1.1.0/

Hangs

bash ./debian/tests/run-unit-test

Does not hang

R
setwd("tests")
library("plumber")
library("testthat")
test_check("plumber", reporter = NULL) #to get more info, otherwise test_check("plumber")

Cut the hanging part out

rm /usr/share/doc/r-cran-plumber/tests/testthat/test-plumber-run.R
bash ./debian/tests/run-unit-test
nileshpatra commented 3 years ago

ACK, apologies for the noise. I can confirm that this works on running manually, had to wait for a few more minutes. Then, I've no clue why the script does not work :(

nileshpatra commented 3 years ago

@meztez

If I run this manually in the upstream test directory, then this chokes as well on exactly plumber-run:

$ LC_ALL=C R --no-save < testthat.R But running via interaction works fine. Not sure why this happens

meztez commented 3 years ago

Reproducible short test:

test.R

library(plumber)
later::later(httpuv::interrupt)
force( pr() %>% pr_run())
Rscript test.R

i386 hangs

amd64 - ok

nileshpatra commented 3 years ago

Yep, it works perfect on amd64. It seems to hang at this on i386:

$ R --no-save < test.R
> library(plumber)
> later::later(httpuv::interrupt)
> force( pr() %>% pr_run())
Running plumber API at http://127.0.0.1:4700
Running swagger Docs at http://127.0.0.1:4700/__docs__/

.... continues running forever
meztez commented 3 years ago

@nileshpatra I don't think later is being executed. Might have to skip on arch. We only use later for that particular test.

nileshpatra commented 3 years ago

@meztez fair enough, I will skip that test on i386. Thanks a lot for all the help! :-)

schloerke commented 3 years ago

Wow! Great debugging @meztez and @nileshpatra !


@wch Have you run into this issue before? Works when run manually, but does not work when run non-interactively on i386.

httpuv::interrupt() doesn't throw, but rather sets httpuv:::.globals <- TRUE. So I don't think https://github.com/r-lib/later/pull/102#issuecomment-531027979 is related.

wch commented 3 years ago

I can't think of any reason why it would behave one way on i386 but another way on amd64. Is the later() callback not executing at all?

meztez commented 3 years ago

@wch I don't think it is. Tested by replacing with later(~cat("wouf")). Did not see any wouf. I can't figure out yet why it would only fail on i386/debian unstable. Windows i386 works fine.