experimentalSessionSupport breaks shareAcrossSpecs

[IanVS]

It took me a long time of scratching my head to realize that my specs were recomputing and failing because shareAcrossSpecs was not working correctly, due to having experimentalSessionSupport enabled, which clears the Cypress.env before each test, while cypress-data-session relies on that cache to store the results.

I think it would be good to throw a clear error if it's detected that experimentalSessionSupport is enabled and shareAcrossSpecs is set as well.

[IanVS]

Maybe this is not quite true, I see in the code that Cypress.env() is not used for shareAcrossSpecs, but it is used to determine whether to recompute. I can't figure out why, but running the tests a second time is not finding anything in Cypress.env(), which causes them to recompute and fail...

[IanVS]

OK, I think I see. I was trying out a hard reload, which I saw you do in one of your videos. This does seem to clear out Cypress.env(), which forces setup() to run again. Is that intentional, or maybe a bug? And yes, experimentalSessionSupport causes the same thing, setup is forced to run between specs.

[bahmutov]

Hard reload is same as loading a different spec and should load the value from the plug-in space. If it does not, it’s a bug

…

Sent from my iPhone

On Dec 14, 2021, at 22:17, Ian VanSchooten ***@***.***> wrote:  OK, I think I see. I was trying out a hard reload, which I saw you do in one of your videos. This does seem to clear out Cypress.env(), which forces setup() to run again. Is that intentional, or maybe a bug? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[IanVS]

I think it does load the saved value, but not the timestamp that is saved into Cypress.env(). So, since it cannot find a timestamp, it runs setup() again, which in my case causes an error if it has already run.

[bahmutov]

Ohh could be!

…

Sent from my iPhone

On Dec 14, 2021, at 22:32, Ian VanSchooten ***@***.***> wrote:  I think it does load the saved value, but not the timestamp that is saved into Cypress.env(). So, since it cannot find a timestamp, it runs setup() again, which in my case causes an error if it has already run. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[bahmutov]

Hey @IanVS can you create a simple reproducible example showing the problem? I have checked the spec https://github.com/bahmutov/cypress-data-session/blob/main/cypress/integration/dependent-shared.js that has shared value with a dependent session, and that does have the timestamps correctly handled.

[IanVS]

I don't have any dependent sessions. I'll try to make a test, though. 👍

[IanVS]

I've opened #37 with an example of what I'm seeing.

[github-actions]

🎉 This issue has been resolved in version 1.13.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[IanVS]

Great, my tests are passing now with the new version. Thanks for the fix!