Explicit save() of cassettes?

[andersthomson]

Hi,

Thanks for a great tool! I use it extensively for running test. one thing I've noticed is that whenever in captuing mode, saving http traffic, it appears to save the cassette to disk for each new track. It appears to entail both json marshaling and a disk write. Some of my tests are long, with thousands of requests, and this amount of writing cause the capturing phase to grind to a crawl when the cassette gets larger in size.

Would it be possible to defer the (json rendering and) writing to disk until an explicit .Save() call is made?

Thanks!

[seborama]

Hi

So sorry about the silence: I wasn't aware you had raised an issue. Somehow I didn't get an email. I need to check my settings...

The reason for saving cassettes early was to ensure they exist. I also suspect there were causality reasons but I don't remember exactly what off the top of my head.

I'll try and have a look into this in the near future.

Regards!

[seborama]

Hi @andersthomson ,
Could you give more context about the need to keep cassettes in memory?

govcr works by recording a request the first time it is made and replaying it after that.
In practice, this means that govcr executes requests a lot faster than plain http because it acts as a cache. You only incur a save the first time a track is recorded.

Are you only making new live requests? In such case, you might be misusing govcr and not matching your requests properly (the doc, the cookbook and examples show how to deal with request matching).

If by nature you need your requests to be executed live all the time, govcr is just not needed. Perhaps you're using gvcr to record requests (and not replay)? I'd recommend you just implement your own custom http.Transport, as you will get better performance: govcr implements a rule parser which would be needless if what you want is a plain recorder (in fact, Go already has that in the test packages).