Bug #15258
closed[Workbench] Report problem/Show version popup failing
Description
When trying to use the 'Show version' or 'Report a problem' menu items on Workbench on one of our dev clusters, I get the following error on the brower's javascript console:
[Error] Failed to load resource: the server responded with a status of 422 (Unprocessable Entity) (report_issue_popup, line 0)
Checking workbench's logs I'm seeing this:
#<ActionView::Template::Error: uninitialized constant ActionView::CompiledTemplates::AppVersion Did you mean? ActionView::VERSION> /var/www/arvados-workbench/current/app/views/application/_report_issue_popup.html.erb:19:in `_app_views_application__report_issue_popup_html_erb__2330610321802802077_33518400' /var/www/arvados-workbench/shared/vendor_bundle/ruby/2.3.0/gems/actionview-5.0.7.2/lib/action_view/template.rb:159:in `block in render' /var/www/arvados-workbench/shared/vendor_bundle/ruby/2.3.0/gems/activesupport-5.0.7.2/lib/active_support/notifications.rb:166:in `instrument' /var/www/arvados-workbench/shared/vendor_bundle/ruby/2.3.0/gems/actionview-5.0.7.2/lib/action_view/template.rb:354:in `instrument' […] /usr/lib/ruby/vendor_ruby/phusion_passenger/rack/thread_handler_extension.rb:97:in `process_request' /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:152:in `accept_and_process_next_request' /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:113:in `main_loop' /usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler.rb:416:in `block (3 levels) in start_threads' /usr/lib/ruby/vendor_ruby/phusion_passenger/utils.rb:113:in `block in create_thread_and_abort_on_exception' {"method":"GET","path":"/report_issue_popup","format":"js","controller":"ActionsController","action":"report_issue_popup","status":422,"duration":488.06,"view":0.14,"request_id":"req-v73s9v0b17x792rwg55d","params":{"action_method":"post","current_location":"https://workbench.c97qk.arvadosapi.com/users/welcome?return_to=%2F","current_path":"/users/welcome?return_to=%2F","popup_type":"version"},"@timestamp":"2019-05-21T19:06:29.394Z","@version":"1","message":"[422] GET /report_issue_popup (ActionsController#report_issue_popup)"}
It seems that this is related to the environment at which the rails app is running, because it isn't failing on arvbox or running workbench locally against one of the dev clusters.
Updated by Lucas Di Pentima over 5 years ago
- Subject changed from [Workbench] Report issue popup failing to [Workbench] Report problem/Show version popup failing
Updated by Tom Morris over 5 years ago
- Target version set to 2019-05-22 Sprint
- Release set to 15
Updated by Lucas Di Pentima over 5 years ago
- Assigned To set to Lucas Di Pentima
Updated by Lucas Di Pentima over 5 years ago
- Target version changed from 2019-05-22 Sprint to 2019-06-05 Sprint
Updated by Lucas Di Pentima over 5 years ago
Taking a closer look at the rails 5.0 release notes, I encountered this one:
- Disabled autoloading of classes in production environment - commit: https://github.com/rails/rails/commit/a71350cae0082193ad8c66d65ab62e8bb0b7853b
Commit discussion: https://github.com/rails/rails/issues/13142#issuecomment-74586224
Updated by Lucas Di Pentima over 5 years ago
- Status changed from New to In Progress
Updated by Lucas Di Pentima over 5 years ago
Following the suggestion at https://github.com/rails/rails/issues/13142#issuecomment-275492070, I added "#{Rails.root}/lib"
to the list of eager loading paths on c97qk
and the issue was fixed.
This behavior occurs on production environments, and I'm not seeing an straightforward way to write a test for it.
Also, maybe we should also apply the fix to the API server? we haven't detected any issue with it but maybe it would be convenient to stay on the safe side? I'm currently running the entire API server's test suite and seems to go ok.
Updated by Lucas Di Pentima over 5 years ago
After discussing the previous question on chat, the API Server won't receive the same fix because it doesn't need it, as it doesn't have the config.autoload_paths
setting.
Fix at 4837e08b7 - branch: 15258-wb-report-issue-bugfix
Test run: https://ci.curoverse.com/job/developer-run-tests/1252/
WB integration re-run at: https://ci.curoverse.com/job/developer-run-tests-apps-workbench-integration/1296/
Updated by Lucas Di Pentima over 5 years ago
After having to run 4 times the integration tests to get a success because of PhantomJS dying:
- https://ci.curoverse.com/job/developer-run-tests-apps-workbench-integration/1295/
- https://ci.curoverse.com/job/developer-run-tests-apps-workbench-integration/1296/
- https://ci.curoverse.com/job/developer-run-tests-apps-workbench-integration/1297/
- https://ci.curoverse.com/job/developer-run-tests-apps-workbench-integration/1298/ (success!)
...I came up with what I think is a better solution. Instead of using eager loading, explicitly require the files under /lib/
where needed (there are just 2 files, so it was simple). This has the benefit of exposing the bug on development & test environments.
Updates at a551aee4b
Test run: https://ci.curoverse.com/job/developer-run-tests/1253/
Updated by Lucas Di Pentima over 5 years ago
- Status changed from In Progress to Resolved
Applied in changeset arvados|8cd99fc692479db9c2aaa211d34ce7d62df47328.