Issue with ThreadStatic/AsyncLocal Variables Being Set to Null After Migrating from SpecFlow to Reqnroll (Playwright, NUnit)

[tdesborough]

Previously posted here: #428

I've tried to migrate to the suggested solution, using AsyncLocal variables however this gave me the same issue as when using ThreadStatic where the variables would be set to null as the thread has been killed. Ideally I don't want to be passing these variables down to my steps, pages and components for everything and wondered if there might be another solution on how to resolve this? As this isn't an issue when using SpecFlow, it's making the migration path to Reqnroll difficult.

The ThreadStatic variables are used for the BrowserContext, Browser, ActivePage as an example of their uses and are used to differentiate between each NUnit thread when ran in parallel execution.

Technology Used: .NET, Playwright, NUnit

Description:
I recently migrated from SpecFlow to Reqnroll using the provided migration guide. However, after running a test, I encountered an issue where the ThreadStatic or AsyncLocal variables, which are initialized using the BeforeFeature hook, are being set to null. This problem only arose after the migration.

I have tried both the compatibility migration and namespace migration, but the issue persists.

Details:

• During debugging, I can confirm that the browserContext and activePage ThreadStatic variables are successfully set initially.
• Shortly after, these variables are set to null.
• These ThreadStatic variables are initialized using the BeforeFeature hook.
• I am using the following NuGet packages:
  • Reqnroll compatibility for Playwright
  • Reqnroll NUnit
  • Reqnroll compatibility

Steps to Reproduce

• Playwright .NET Project with NUnit and SpecFlow
• Migrate the project to Reqnroll
• Initialise ThreadStatic variables using the BeforeFeature hook
• When running the project the ThreadStatic variables will suddenly be set to null after they've successfully initialised

[gasparnagy]

SpecFlow (v3) was not really async. It used a hack to run the async hooks and step definitions from a sync context. SpecFlow v4 (never released) introduced real async handling and that (naturally) changed the behavior.

In my opinion, using the [ThreadStatic] and AsyncLocal for this purpose is a bad practice in general. As mentioned it in the related issue, you can have a look at our sample app (https://github.com/reqnroll/Sample-ReqOverflow/tree/main/ReqOverflow.Specs.WebUI) that solves all this without needing [ThreadStatic] and AsyncLocal.

So primarily I recommend to remove these constructs and build up the infrastructure without them.

Using AsyncLocal does not work in the same way as [ThreadStatic], because it only allows you to flow the information "down" and never "up". I can really recommend reading through the great article of Stephen Toub (https://devblogs.microsoft.com/dotnet/how-async-await-really-works/), especially the "ExecutionContext" section for details.

Following the logic of that, you cannot set an AsyncLocal value in a hook, because that would only be propagated down to the hooks "nested calls", but not to the step definitions (that are kind of "siblings"). This was working in SpecFlow v3, because the hack we have used there had a negative side-effect that enabled this, but this was never a model that supposed to work based on the logic of AsyncLocal.

Reqnroll has a more correct async implementation now. As I wrote in the issue, you can study the related tests in Reqnroll:

Reqnroll/Tests/Reqnroll.RuntimeTests/Bindings/BindingInvokerTests.cs

Line 346 in 182e933

[InlineData("Boxed value is initialized in ctor and also set in async step def", AsyncLocalType.Boxed, "Async", "42")] // the change in async step def is preserved because of boxing

As I also wrote there, what you can do is to initialize the AsyncLocal in the constructor of the class to a reference type and set the properties of that reference type in the hook.

I hope this helps.