Bug #15258

[Workbench] Report problem/Show version popup failing

Added by Lucas Di Pentima about 2 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
05/22/2019
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
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

Task #15266: Review 15258-wb-report-issue-bugfixResolvedTom Clegg

Associated revisions

Revision 8cd99fc6
Added by Lucas Di Pentima about 2 months ago

Merge branch '15258-wb-report-issue-bugfix'
Closes #15258

Arvados-DCO-1.1-Signed-off-by: Lucas Di Pentima <>

History

#1 Updated by Lucas Di Pentima about 2 months ago

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

#2 Updated by Tom Morris about 2 months ago

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

#3 Updated by Lucas Di Pentima about 2 months ago

  • Assigned To set to Lucas Di Pentima

#4 Updated by Lucas Di Pentima about 2 months ago

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

#5 Updated by Lucas Di Pentima about 2 months 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

#6 Updated by Lucas Di Pentima about 2 months ago

  • Status changed from New to In Progress

#7 Updated by Lucas Di Pentima about 2 months 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.

#8 Updated by Lucas Di Pentima about 2 months 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/

#9 Updated by Tom Clegg about 2 months ago

LGTM, thanks

#10 Updated by Lucas Di Pentima about 2 months 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/

#11 Updated by Tom Clegg about 2 months ago

Yes, LGTM, thanks!

#12 Updated by Lucas Di Pentima about 2 months ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF