some notes

[maelle]

• opencage itself was having vcr tests problem due to memoise but memoise has been released on CRAN cc @dpprdan so I think the issue with the failing test might be something related to the sensitive data filtering?

• reg rtweet that's on Windows only, not sure yet why the token can't be found.

[maelle]

maybe vcr::vcr_test_path("fixtures") doesn't work well on Windows? cc @sckott

[sckott]

what exactly is the problem?

[maelle]

on Windows the rtweet token created in setup-tidytags.R (a fake token needed for tests without secrets available) isn't found whereas on Ubuntu it is found and the rtweet-related tests pass.

[sckott]

okay, can you replicate this on your own windows machine? or only on windows CI?

[sckott]

@maelle where is the evidence that makes you think vcr_test_path is to blame here?

[maelle]

No evidence, i was just gathering ideas

[maelle]

It was on CI

[sckott]

i've not used vcr_test_path so I'm not super familiar with it - i don't know why, though it doesn't work with devtools::test() which is how I run tests locally (via a make command)

checked vcr_test_path on windows GH Actions CI with rplos - and it seems to work https://github.com/ropensci/rplos/runs/1825458162 on windows

[maelle]

ok so the problem must lie elsewhere.

The other unrelated bug we observed, that seems more serious, is https://github.com/ropensci/vcr/issues/221

[maelle]

@bretsw actually were some of the rtweet tests outside of cassettes? Did you make some progress on this?

[maelle]

ah no the failing tests are inside cassettes.

[maelle]

now the other builds are successful (the ones not on Windows), what was changed @bretsw ?

[bretsw]

now the other builds are successful (the ones not on Windows), what was changed @bretsw ?

@maelle The only thing I changed prior to those successful builds (minus Windows) was to completely clear out my GitHub Actions secrets. So it seems like however I had stored the OpenCage token in there must have been problematic.

[bretsw]

So it seems like the remaining issue is related to rtweet tokens on Windows only

[maelle]

so weird and interesting. did your secret have ' or " in it? because if that's the case I definitely want to add it as a gotcha in the HTTP testing book!

[bretsw]

It was stored with "

OPENCAGE_KEY="11a1111a111a1a1a1a111111a1aa11a1"

because that follows how keys are saved in my local .Renviron file. Any clarity you can add in the book on that regard would be appreciated!

[bretsw]

(hopefully it's obvious that 11a1111a111a1a1a1a111111a1aa11a1 is a fake key)

[maelle]

ahah yes it is :grin:

I think what is BAD is

What is GOOD is

[bretsw]

Perfect! Thanks for screenshots! So helpful :)

[bretsw]

on Windows the rtweet token created in setup-tidytags.R (a fake token needed for tests without secrets available) isn't found whereas on Ubuntu it is found and the rtweet-related tests pass.

@maelle any new ideas on this one? I'm really at a loss re: why the build works on Mac and Ubuntu but fail on Windows. Something weird is going on with that rtweet token

[maelle]

I don't have any good guess at the moment. :thinking:

[bretsw]

on Windows the rtweet token created in setup-tidytags.R (a fake token needed for tests without secrets available) isn't found whereas on Ubuntu it is found and the rtweet-related tests pass.

@maelle, as I look at the error log, the Windows build fails at rtweet:::rstats2twitter_client(). When I look at this function in rtweet (https://github.com/ropensci/rtweet/search?q=rstats2twitter_client), I see in tokens.R (lines 570-584):

rstats2twitter_client <- function() {
  if (!interactive()) {
    stop("API user token required. see http://rtweet.info/articles/auth.html for instructions",
      call. = FALSE)
  }
...

Again, I don't know why interactive() is triggering something in the Windows build that's not elsewhere, but it seems like the failure to build is somewhere in this realm.

Gargle seems to address the issue of non-interactivity: https://cran.r-project.org/web/packages/gargle/vignettes/non-interactive-auth.html

rtweet saves Twitter tokens to an .rds file, so perhaps running readRDS(".rtweet_token.rds") manually would retrieve the file created by rtweet::create_token() in tidytags?

I feel like I'm a bit out of my depth here, and maybe you've worked through all these possibilities already. I'm hoping there's something in here that helps, though.

[sckott]

I'm not sure what exactly is going on, but I'll have a look

[bretsw]

Thank you!

[sckott]

If I were you I'd maybe make a git branch, remove all tests except for the ones that use rtweet, and just test on windows, and add VCR_TURN_OFF: true to your gh actions config file which will ignore vcr and do real http requests (assuming that's okay to do on CI?, I don't know if it is or not) - then you can see if it's an issue that involves vcr or not - I don't think it does but may be wrong

[bretsw]

I'll give this a shot this weekend/early next week. Thanks!