🎩 What? Why?

In the past we added the min-max threads limit as 1:1 to the puma server running during the "system" / E2E tests at #7366.

The reason was that there were specific tests that were constantly timing out and we figured we could fix this issue by limiting the threads to 1:1 allowing the tests to finish properly.

The particular test that was freezing was related to the admin newsletters view. Later during Ruby 3 upgrade, we figured out that there was actually a thread safety issue with Webpacker which caused the newsletters view to fail when using more than a single thread. This was fixed at #9203.

So I believe after #9203 the original issue described at #7366 no longer exists which means we can remove the threads limit.

I'm not expecting any major benefits from this but I feel it might be a good idea to also run the tests in multi-threaded mode so that we can identify possible further thread safety issues when they arise.

📌 Related Issues

• Related to Configure capybara puma maximum threads to 1 #7366, Fix webpacker thread safety #9203

Testing

• Run the test described at Configure capybara puma maximum threads to 1 #7366 multiple times in a row
• Expect all test runs to complete without timing out or errors

📋 Checklist

• ❓ CONSIDER adding a unit test if your PR resolves an issue.
• ✔️ DO check open PR's to avoid duplicates.
• ✔️ DO keep pull requests small so they can be easily reviewed.
• ✔️ DO build locally before pushing.
• ✔️ DO make sure tests pass.
• ✔️ DO make sure any new changes are documented in docs/.
• ✔️ DO add and modify seeds if necessary.
• ✔️ DO add CHANGELOG upgrade notes if required.
• ✔️ DO add to GraphQL API if there are new public fields.
• ✔️ DO add link to MetaDecidim if it's a new feature.
• ❌AVOID breaking the continuous integration build.
• ❌AVOID making significant changes to the overall architecture.