EDU-3510: Python: Added paragraph that warns about pytest.fixture(scope="session") with test server

[edmondop]

What does this PR do?

Addresses #3111 . When running tests in a project I noticed:

• Time skipping wasn't working even if it was enabled
• samples-python test never reuse the same workflow environment with timeskipping

This additional paragraph should warn developers familiar with pytest.fixtures not to use the scope session for caching the workflow environment

[fairlydurable]

Created SDK-2941 to review

[cretz]

Suggested change

	pytest.fixture(scope="session")
	@pytest.fixture(scope="session")

If you do keep this, need @

[edmondop]

Thanks for catching this!

[fairlydurable]

Thanks, @cretz. Back to you @edmondop

[edmondop]

I have accepted all @cretz suggestion, thank you @cretz . I see two workflows are not passing, do I need to do something else?

[cretz]

I am not sure this works without @pytest_asyncio.fixture and async and await. Have you tested this code? And for many, they may prefer a "session" scoped start_local instead of time skipping even though this only demonstrates time skipping.

[edmondop]

That's a good point, was using the auto-mode in my tests https://pytest-asyncio.readthedocs.io/en/latest/reference/configuration.html but I agree that being explicit works better

[edmondop]

Should be addressed on @cretz

[cretz]

It appears the workflow_environment() function is now duplicated in this snippet

[edmondop]

It is to show the good and bad example, do you think one of the two fixtures should be named differently ?

[cretz]

Yeah, I think it's a bit confusing to even have a bad example unless it's labeled more clearly and in a separate snippet. Many of our users just grab the first snippet and move on.

So in this case, we do want start_local to be used by users and used across tests, but if they need start_time_skipping you are correct that it should be per test. So maybe we should have both forms, named differently, with comments above each on why start-local is session scoped and start-time-skipping is not.

[fairlydurable]

@edmondop Thanks for all your work on this. Please ping me and let me know when it is ready to move forward. Cheers!

[fairlydurable]

@cretz @edmondop Just touching base to check the status of this PR. Thank you both.

[cretz]

@fairlydurable - sorry I missed your comment until now. I think https://github.com/temporalio/documentation/pull/3113/files#r1866332621 still needs to be addressed