Cucumber JVM parallel execution: hook thread-affinity guarantee for scenario-scoped @Before/@After

Thread-affinity uncertainty for scenario hooks

When running Cucumber JVM scenarios in parallel via JUnit 5's parallel execution or Cucumber's --threads option, reliable management of thread-local resources such as WebDriver instances or database connections depends on whether @Before and @After hooks execute on the same thread as their associated scenario. The current documentation does not explicitly guarantee this thread affinity, leaving a gap for teams that rely on thread-local storage for scenario-scoped state.

Constraints and observed variability

Behavior may differ between Cucumber 6.x and 7.x series, and JUnit 5 parallel modes (SAME_THREAD vs CONCURRENT) interact with Cucumber's internal executor in ways that are not fully specified. Custom thread pools or executor services can further alter hook threading unpredictably. Users have also reported inconsistent hook execution order when multiple glue classes define hooks with identical order values under parallel execution.

Without a documented guarantee, teams cannot confidently design cleanup logic that assumes the hook runs on the scenario's thread, risking resource leaks or cross-scenario contamination.

• Does Cucumber JVM guarantee that scenario-scoped @Before and @After hooks execute on the same thread as the scenario body?
• How do JUnit 5 parallel execution modes affect this guarantee across Cucumber 6.x and 7.x versions?
• Is there a supported mechanism to enforce or query hook thread affinity for custom resource management?