Arvados

Notes on the fix I implemented:

The issue was occurring due to conversion of percentages computed into integers using ceil method. Due to this, in this particular job's case, the total of the percentages computed is > 100% (99% success and 2% failures to be precise, instead of 98.8% success and 1.2% failures) and hence the offending failures percentage was not rendered.

I removed the conversion into integers by removing the ceil method and I now see the failures in red.

Let me know if this is not sufficient, and if we indeed want to display actual numbers instead of the progress bar.

Radhika,

I took a look at 52f0c22, and it was a definite improvement. It would help avoid situations where "failed" progress is nudged off the edge of the bar by rounding. Thanks.

However, I wasn't sure if it would be sufficient to cover some of the related situations that Tom talked about in the description. I pinged him about it, and he clarified which parts he considers requirements for this story. Could you please take a look and update the branch to match? Thank you.

See also #3073

Reviewing 2c7b720

I'm getting a bunch of Workbench test failures. There are lots of 422s with a stack trace starting like:

Processing by ProjectsController#index as HTML
  Rendered projects/_show_dashboard.html.erb (178.0ms)
#<TypeError: no implicit conversion of Symbol into Integer>
/home/brett/repos/arvados/apps/workbench/app/views/projects/_show_dashboard.html.erb:36:in `[]'
/home/brett/repos/arvados/apps/workbench/app/views/projects/_show_dashboard.html.erb:36:in `block (2 levels) in _app_views_projects__show_das
hboard_html_erb__2688463059846288523_94558320'
/home/brett/repos/arvados/apps/workbench/app/views/projects/_show_dashboard.html.erb:35:in `each'
/home/brett/repos/arvados/apps/workbench/app/views/projects/_show_dashboard.html.erb:35:in `block in _app_views_projects__show_dashboard_html
_erb__2688463059846288523_94558320'

I don't get these failures on master. Can you please investigate?

Everything else pertains to _running_component.html.erb:

• If I'm following the blocks correctly, I'm not sure how it's possible to get into the elsif current_job[:state] == "Queued" branch. It looks like a follow-up to if current_job, meaning if we get to the elsif, current_job is either false or nil, and calling [] on it will crash. Am I missing something here? If not, should any of this get rolled into the new Queued state branch?
• You can use Rails' pluralize method to pluralize "tasks," rather than manually adding an "s".
• The column offset comments don't seem to be consistent. It seems like they all document what the offset is before the following div, except the first one, which lists 3 instead of 0. Can you please make them consistent, or otherwise clarify what's going on here?

Thanks.

Brett Smith wrote:

Reviewing 2c7b720

I'm getting a bunch of Workbench test failures. There are lots of 422s with a stack trace starting like:

[...]

I don't get these failures on master. Can you please investigate?

Fixed

Everything else pertains to _running_component.html.erb:

• If I'm following the blocks correctly, I'm not sure how it's possible to get into the elsif current_job[:state] == "Queued" branch. It looks like a follow-up to if current_job, meaning if we get to the elsif, current_job is either false or nil, and calling [] on it will crash. Am I missing something here? If not, should any of this get rolled into the new Queued state branch?

You're right, it got screwed up somewhere down the line. I reorganized that whole block of code to fix some problems and it should be easier to follow (and properly indented!)

• You can use Rails' pluralize method to pluralize "tasks," rather than manually adding an "s".

Fixed.

• The column offset comments don't seem to be consistent. It seems like they all document what the offset is before the following div, except the first one, which lists 3 instead of 0. Can you please make them consistent, or otherwise clarify what's going on here?

Fixed.

Peter Amstutz wrote:

• If I'm following the blocks correctly, I'm not sure how it's possible to get into the elsif current_job[:state] "Queued" branch. It looks like a follow-up to if current_job, meaning if we get to the elsif, current_job is either false or nil, and calling [] on it will crash. Am I missing something here? If not, should any of this get rolled into the new Queued state branch?

You're right, it got screwed up somewhere down the line. I reorganized that whole block of code to fix some problems and it should be easier to follow (and properly indented!)

Thanks. The new current_job[:state] "Queued" branch says it's column offset 3, but it's actually 5. Please go ahead and merge with that fixed.