Response sequence #35
Conversation
According to the VCR docs[1] identical requests in a cassette should be replayed in sequence, this can be useful for writing tests for behaviour such as retrying after receiving a 500 response. [1]: https://relishapp.com/vcr/vcr/v/2-9-3/docs/request-matching/identical-requests-are-replayed-in-sequence
There are definitely much nicer ways to implement this, but as a brute force starting point it works.
|
Thanks for the PR. The link to the I think the ordering scenario makes sense. I'm wondering whether it should be default or an optional parameter (safer to make it optional?). |
|
Heh, seems you can't use numbers as url references in GitHub flavoured markdown. Correct link is https://relishapp.com/vcr/vcr/v/2-9-3/docs/request-matching/identical-requests-are-replayed-in-sequence |
|
The current behaviour is to ignore all but the first response in the cassette that matches a request. I guess if someone had extra responses that weren't used then it could cause issues if it was on by default. Maybe it could start as an optional parameter then get switched on by default in some future breaking version? |
|
Thanks for the comment.
I was thinking it may be safer approach, but
This part sounds like it's just a incorrect behavior (I couldn't come up with good option name to explain the behavior difference), and also re-recording would resolve the possible issue. With the above, I'll be merging and release as v0.7.0 (with some description). |
|
Sounds good, thanks :) |
|
Thanks! |
According to the VCR docs identical requests in a cassette should be replayed in sequence, this can be useful for writing tests for behaviour such as retrying after receiving a 500 response.
I don't think this is the best implementation, but it's a starting point for discussion (and allows me to start relying on this behaviour).
Also, I'm sure there must be a much nicer way to do
Enum.reverse(acc) ++ tail ++ [response], but I'm pretty much a complete beginner to writing Elixir.