| I had heard that Capyabara-based tests were going to be incorporated in Rails. As the multi-threaded concurrent nature of these always makes things a pain, hard to get right, leading to much pain for devs with non-trivial test suites -- I was curious to see how they'd handle it, if there'd be an 'official' Rails solution, ideally backed by some deep Rails knowledge. I was surprised that they've chosen to use the 'shared database connection accross two threads' approach. While this was for a while popular approach amongst people trying to figure out the best way to use Capybara-based tests with Rails -- mostly because you get to keep transaction-based database cleanup -- it was largely determined through experience to be too flaky. ActiveRecord's architecture just wasn't designed for a Connection object (representing a single actual network connection) to be shared between two threads, it's not a thread-safe object. José Valim originally proposed the approach in a gist, and you can see a long discussion among people having hard-to-debug problems with it here: https://gist.github.com/josevalim/470808 There are other such threads in various places from over the years. Here's one blogger explaining the race condition issue, with the ActiveRecord architecture not actually being concurrency-safe in this use case: http://influitive.github.io/news/2015/09/02/dont-use-shared-... I thought I remembered Valim actually posting somewhere himself "Yeah, turns out, that wasn't a great idea", but now I can't find it. (It may be that José deleted most of his tweets when he left twitter?) So I'm surprised Rails took this approach. I can't tell for sure if the approach now in Rails just basically takes Valim's approach (violating AR's concurrency contracts and expectations), or actually takes a new approach that will truly be concurrency-safe, while somehow still sharing the connection (another lock somewhere? Are AR connections in general now safe for sharing between threads? Cause that'd be huge if it was true in the general case). https://github.com/rails/rails/pull/28083 Can anyone else? Either way, reliable Capybara has been a real challenge to a lot of devs due to race conditions, it would be shocking if Rails gets it right on the first try, when many devs haven't managed to figure out a right way to do it in years of trying! I expect lots and lots of frustrated devs running into race conditions and filing Issues. It will be interesting to see if this ends up a maintained feature, or another Rails internal abandonware. If dhh and his team use it, and run into the race conditions, then it will certainly be addressed; otherwise, some 'difficult' Rails features seem to sometimes end up basically abandonware. |