Join GitHub today
Publish AS::Executor and AS::Reloader APIs #23807
These should allow external code to run blocks of user code to do "work", at a similar unit size to a web request, without needing to get intimate with ActionDispatch.
The theory is that interested callers (Sidekiq, ActionCable) can just do:
Rails.application.reloader.wrap do # run some user code end
.. and we'll take care of the interlock, code reloading, returning AR connections to the pool, and anything else that might be relevant.
This reverts changes made to integration tests in PR #23807. The issue happens when using capybara with a driver that needs to start a server in a separate thread like (poltergeist, selenium, etc). Both threads the capybara server one and the test thread end running syncronize over the interlock.
The integration.rb part of the changes introduces an issue when using capybara with a driver that needs to start a server in a separate thread like poltergeist, selenium, etc.
Both threads, the test thread and the capybara server one run synchronize over the interlock so the server can't execute when receives the request because it's locked.
I don't know what was the intention of the changes in integration.rb were but doesn't seem to have sense, given that all it adds is this lock and QueryCache which doesn't make much sense per integration test as it's working with this changes.
Fixed here cf075d9
I see you touched
Does this pull request resolve the problem? If not, what is "the right way" to approach the problem?
Related questions in stackoverflow:
…n guides [ci skip] Guides should be updated because ActionDispatch::LoadInterlock was replaced with ActionDispatch::Executor at rails#23807.
…n guides [ci skip] Guides should be updated because ActionDispatch::LoadInterlock was replaced with ActionDispatch::Executor at #23807.