what behavior do we want when file on disk is gone for any reason

[sckott]

That is, say a http request uses vcr for a test. That http request writes to disk. Later the file on disk is somehow deleted, or moved. The test is run again, but file on disk is gone. What behavior do we want? Right now we have, with example from rnoaa package:

With the file present

✔ |  OK F W S | Context
✔ |   6       | arc2 [1.3 s]

After deleting the file

✔ |  OK F W S | Context
✖ |   4 1 1   | arc2 [1.1 s]
────────────────────────────────────────
test-arc2.R:13: warning: arc2 returns the expected output
cannot open file '../files/daily_clim.bin.19830101.gz': No such file or directory
test-arc2.R:13: error: arc2 returns the expected output
cannot open the connection

Is that behavior good? Do we want a more meaningful message? Do we want to have an explicit check that a file is present in vcr and stop with message if not present?

My gut reaction is that the current behavior is pretty clear, but maybe it could be better?

cc @maelle @aaronwolen

[maelle]

Maybe instead of "file" the message could say "file supposedly cached by vcr" or so? The phrase I'm giving is very bad, what I mean is a phrase that'd make it clear that what's gone should have been cached / is referenced to in a cassette?

[sckott]

yeah, maybe ideally point to the code line in the casssette that references the file that is gone. not sure if that's easy to do or not

[maelle]

even just the cassette filename would help

[sckott]

true, good point

[aaronwolen]

Hey @sckott, late to the game here...

This may (or may not) be relevant to an issue I'm currently facing, so let me make sure I'm understanding your question correctly. Using this test as a reference, which file is missing:

• the original that was directly downloaded (ie /tmpdir/41001c1990.nc)?
• or the one that was copied to write_disk_path (ie /tmpdir/files/41001c1990.nc)?

[sckott]

thanks @aaronwolen - I think the file that is under the directory specified by write_disk_path - let me know if your issue is related to this threadd

[sckott]

Closing this. I think this is addressed adequately by current behavior. That is, a failure if a file is gone states in testthat errors where the error occurred (in which line of a test file) - I don't think we need to do a lot of work just to get the cassette name when the user can go to that line in the test file given by the testthat error.