Fix turning off VCR not working when server thread already started #764
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When VCR is first used in the main (test) thread, it initializes a context, holding the status of whether VCR is turned off. When another thread is started (ie. app server), VCR initializes a context there by duplicating the main thread's context and linking to the main thread's context. If you turned off VCR in the main thread after it's context was duplicated to an additional thread, the additional thread wouldn't see the new turned off status (since it was only on the linked context), so it'd fail thinking VCR was still turned on but no cassette was inserted when a request was made. Now we check both the current thread's context, and the linked (main) thread's context to see if VCR is turned off, to ensure an app server thread can see when VCR is turned off on the main thread. This was most noticeable in Capybara tests with a JS driver where the app server thread was started once upon the first spec needing it, thus duplicating the main thread's context then, but if later specs turned off VCR, the app server thread never had it's context updated to reflect that, nor did it check the main thread's context to see if VCR was turned off there.
|
this looks good to me! |
yiyuanc
approved these changes
Aug 15, 2019
|
(I added formatting markup to the Description of this PR, to ease navigation and skim-reading.) |
krainboltgreene
approved these changes
Dec 24, 2019
krainboltgreene
approved these changes
Dec 24, 2019
|
Thanks for the merge! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
When VCR is first used in the main (test) thread, it initializes a context, holding the status of whether VCR is turned off. When another thread is started (ie. app server), VCR initializes a context there by duplicating the main thread's context and linking to the main thread's context.
If you turned off VCR in the main thread after it's context was duplicated to an additional thread, the additional thread wouldn't see the new turned off status (since it was only on the linked context), so it'd fail thinking VCR was still turned on but no cassette was inserted when a request was made.
Solution
Now we check both the current thread's context, and the linked (main) thread's context to see if VCR is turned off, to ensure an app server thread can see when VCR is turned off on the main thread.
Details
This was most noticeable in Capybara tests with a JS driver where the app server thread was started once upon the first spec needing it, thus duplicating the main thread's context then, but if later specs turned off VCR, the app server thread never had it's context updated to reflect that, nor did it check the main thread's context to see if VCR was turned off there.