From 7ec5055f8c6a14a61907e3f3ae880bb025d1291d Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Fri, 24 May 2024 10:54:04 +0000
Subject: [PATCH] [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci
---
 doc/en/explanation/flaky.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/en/explanation/flaky.rst b/doc/en/explanation/flaky.rst
index 8f2009b7e..7ab85f13d 100644
--- a/doc/en/explanation/flaky.rst
+++ b/doc/en/explanation/flaky.rst
@@ -40,9 +40,9 @@ Even in case of plugins which run tests in parallel, for example `pytest-xdist`_
 It is of course possible (and common) for tests and fixtures to spawn threads themselves as part of their testing workflow (for example, a fixture that starts a server thread in the background, or a test which executes production code which itself spawns threads), but some care must be taken:
 
 * Make sure to eventually wait on any spawned threads -- for example at the end of a test, or during teardown of a fixture.
-* Avoid using primitives provided by pytest (:func:`pytest.warns`, :func:`pytest.raises`, etc) from multiple threads, as they are not thread-safe. 
+* Avoid using primitives provided by pytest (:func:`pytest.warns`, :func:`pytest.raises`, etc) from multiple threads, as they are not thread-safe.
 
-If your test suite uses threads and your are seeing flaky test results, do not discount the possibility that the test is implicitly using global state in pytest itself. 
+If your test suite uses threads and your are seeing flaky test results, do not discount the possibility that the test is implicitly using global state in pytest itself.
 
 Pytest features
 ^^^^^^^^^^^^^^^