Feature Request - Flag to allow unmatched HTTP calls to pass through & record new responses

[Mor Shemesh]

Why do I want it:

We want to use Responses' as a caching layer and have it be a best-effort cache.
Our code makes hundreds of different requests to dozens of domains, and the requests per use-case change pretty frequently as we develop our product.

Responses works great, aside from the fact that we cannot maintain the request-response registry manually and must record the responses instead.
I want the developers to be able to use the caching as smooth as possible.

Our current usage is:

• If this is the first time running a test, record the HTTP requests and responses using _recorder.Recorder and save to a cache file.
• If this is not the first time and we have a recording file, load it for the test using rsps._add_from_file and mock all requests.

The problem:

Currently if our code sends a new request from the last test run, i.e. we changed some internal feature, Responses will raise an exception since the call won't match any request in the registry.
We have to delete the cache file and rerun the test without any cache.

What do I want to be able to do:

I want to have an ever-growing cache file (for each test) with all of our requests and responses, and that it will update with each new yet-unregistered request.
For this I need two things:

1. Add a flag that makes unmatched request pass through responses and work normally.
2. Allow recording and mocking requests simultaneously

Bottom line:

Is there way to do this already and I'm missing something?
If not - Is this something feasible? Should I open a PR for this?

Thanks in advance!

[Maksim Beliaev]

@markstory what are your thoughts on this ?

for me that sounds dangerous and might cause some false positives. What is the purpose of the test if it will regenerate in case of not found matches.
I think testing itself should be "a bit hard", meaning that users should go and have a check of tests if they modified code base.

[Mark Story]

for me that sounds dangerous and might cause some false positives. What is the purpose of the test if it will regenerate in case of not found matches.

I share this concern. Having tests automatically pass through unregistered requests and update a fixture file feels like a workflow that could be built on top of the primitives we already provide.

[Mor Shemesh]

The purpose of this feature request is for the Responses module to be able to act as a cache, If desired, and not just for strict testing.
It is extremely powerful as-is, and I think of properly labeled and behind a feature flag this is very useful.

@markstory I'd love to be able to implement this myself if needed and you think it is unfit for the official package,
could you give me a few pointers as to how to implement such a feature?

[Maksim Beliaev]

@MorAlterya
you can create your own wrapper and catch the exceptions. If exception is raised, you send a real request and cache the value in registry file

[Mark Story]

Building a pass-through cache is outside of the scope of what responses is trying to solve. It expands scope to include managing cache data at the key level and for all entries. The focus of responses has and will continue to be as a aid for testing against external APIs and webservices.