You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the recorded VCR entries only get written to disk on close(). This was intentional as I didn't want partial results getting written to disk in cases like if the tests blew up with an exception and so on.
I feel this "all or nothing" approach is the right default. Having said that, the user may want to write requests/responses immediately for various reasons. Maybe writing a proper shutdown/cleanup phase isn't straightforward in their app (some DI frameworks make this difficult). Adding an option to change the default write strategy might be helpful. The only tricky part is that if you write immediately with certain formats like JSON, then that final } needs to be properly handled. You can't just stream JSON to disk in a straightforward way. I guess either backtrack or use RandomAccessFile? I'm not sure, but that part would need to be investigated.
Besides that though, one downside with the current approach is that the requests/responses are held in memory until close() is called. Maybe it's not too big of a concern, but memory consumption could be decreased by streaming to a temporarily file first. And then on close() move that temporarily file to the "real" path.
The text was updated successfully, but these errors were encountered:
Right now the recorded VCR entries only get written to disk on
close()
. This was intentional as I didn't want partial results getting written to disk in cases like if the tests blew up with an exception and so on.I feel this "all or nothing" approach is the right default. Having said that, the user may want to write requests/responses immediately for various reasons. Maybe writing a proper shutdown/cleanup phase isn't straightforward in their app (some DI frameworks make this difficult). Adding an option to change the default write strategy might be helpful. The only tricky part is that if you write immediately with certain formats like JSON, then that final
}
needs to be properly handled. You can't just stream JSON to disk in a straightforward way. I guess either backtrack or use RandomAccessFile? I'm not sure, but that part would need to be investigated.Besides that though, one downside with the current approach is that the requests/responses are held in memory until
close()
is called. Maybe it's not too big of a concern, but memory consumption could be decreased by streaming to a temporarily file first. And then onclose()
move that temporarily file to the "real" path.The text was updated successfully, but these errors were encountered: