Project

General

Profile

Actions

Bug #15258

closed

[Workbench] Report problem/Show version popup failing

Added by Lucas Di Pentima almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Story points:
-
Release relationship:
Auto

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.


Subtasks 1 (0 open1 closed)

Task #15266: Review 15258-wb-report-issue-bugfixResolvedTom Clegg05/22/2019Actions
Actions #1

Updated by Lucas Di Pentima almost 5 years ago

  • Subject changed from [Workbench] Report issue popup failing to [Workbench] Report problem/Show version popup failing
Actions #2

Updated by Tom Morris almost 5 years ago

  • Target version set to 2019-05-22 Sprint
  • Release set to 15
Actions #3

Updated by Lucas Di Pentima almost 5 years ago

  • Assigned To set to Lucas Di Pentima
Actions #4

Updated by Lucas Di Pentima almost 5 years ago

  • Target version changed from 2019-05-22 Sprint to 2019-06-05 Sprint
Actions #5

Updated by Lucas Di Pentima almost 5 years ago

Taking a closer look at the rails 5.0 release notes, I encountered this one:

Commit discussion: https://github.com/rails/rails/issues/13142#issuecomment-74586224

Actions #6

Updated by Lucas Di Pentima almost 5 years ago

  • Status changed from New to In Progress
Actions #7

Updated by Lucas Di Pentima almost 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.

Actions #8

Updated by Lucas Di Pentima almost 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/

Actions #9

Updated by Tom Clegg almost 5 years ago

LGTM, thanks

Actions #10

Updated by Lucas Di Pentima almost 5 years ago

After having to run 4 times the integration tests to get a success because of PhantomJS dying:

...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/

Actions #11

Updated by Tom Clegg almost 5 years ago

Yes, LGTM, thanks!

Actions #12

Updated by Lucas Di Pentima almost 5 years ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF