Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mccalluc/user files next steps #1772

Merged
merged 13 commits into from Jun 12, 2017
Merged

Conversation

mccalluc
Copy link
Member

@mccalluc mccalluc commented Jun 7, 2017

This continues the work on user file listing begun in #1749. This PR replaces #1759. This is generally about better or more graceful error handling.

@codecov-io
Copy link

codecov-io commented Jun 9, 2017

Codecov Report

Merging #1772 into develop will increase coverage by 1.74%.
The diff coverage is 26.08%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #1772      +/-   ##
===========================================
+ Coverage    39.97%   41.71%   +1.74%     
===========================================
  Files          382      383       +1     
  Lines        25171    26074     +903     
  Branches      1267     1354      +87     
===========================================
+ Hits         10061    10876     +815     
- Misses       15110    15198      +88
Impacted Files Coverage Δ
refinery/data_set_manager/tests.py 99.54% <ø> (ø) ⬆️
refinery/user_files_manager/views.py 55.17% <0%> (-7.33%) ⬇️
refinery/data_set_manager/utils.py 50% <35.29%> (-0.2%) ⬇️
...ui/source/js/tool-launch/ctrls/tool-select-ctrl.js 78.04% <0%> (-1.12%) ⬇️
...rce/js/tool-launch/services/tool-select-service.js 93.33% <0%> (-0.42%) ⬇️
...rce/js/tool-launch/directives/tool-info-display.js 100% <0%> (ø) ⬆️
...ce/js/tool-launch/directives/tool-launch-button.js 100% <0%> (ø) ⬆️
refinery/user_files_manager/tests.py 100% <0%> (ø) ⬆️
refinery/ui/source/js/tool-launch/module.js 100% <0%> (ø) ⬆️
...i/source/js/tool-launch/ctrls/tool-display-ctrl.js 100% <0%> (ø) ⬆️
... and 23 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3a6d688...bec5ea5. Read the comment docs.

except Study.MultipleObjectsReturned:
logger.error('Expected only one study for %s', investigation)
logger.error('Expected only one Study for %s', investigation)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

except (Study.DoesNotExist, Study.MultipleObjectsReturned) as e:

We tend to include e in the logger.

# but there's nothing more to do here.
except:
logger.error('Expected only one assay for %s', study)
logger.error('Expected at least one Assay for %s', study)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as Jennifer's remarks above

assay_uuids
))
)
assert len(assay_uuids) > 0, 'At least one assay must be accessible'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think assert is inline with what we've been doing. We generally have been using try/excepts, but i do enjoy its simplicity. Maybe it could be up for debate?

Presumably
AssertionError is raised? so at the very least that should be handled.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing will go wrong at the next line if assya_uuids == [], except that the solr query constructed is invalid: so it seems best to catch it here. That said, perhaps what we really want is a custom error, that can be caught a couple layers up.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just committed a fix I like: We're inside a method which is building the query string. rather than using errors, we just return None is there query string would be invalid, and then at the top level that can be handled.

@@ -806,10 +800,17 @@ def format_solr_response(solr_response):
solr_response_json = json.loads(solr_response)
except TypeError:
return "Error loading json."
assert solr_response_json['responseHeader']['status'] == 0, \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@scottx611x : I would like to leave this, actually: If solr is returning error responses to us, then we really do have a problem, and letting it bubble up and manifest as a 500 is appropriate: It's not something we can or should recover from.

This assertion isn't necessary for my code, but it will make it easier for any developer in the future by pointing them in the right direction.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mccalluc It may be useful to return HTTP 500 response in a case like this but exceptions should not be left unhandled: "Care must be taken when handling exceptions to ensure proper application cleanup while maintaining useful error reporting." https://doughellmann.com/blog/2009/06/19/python-exception-handling-techniques/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not on the same page right now, but this line shouldn't block the PR. I'll revert it; meanwhile, I've filed #1789 to try to explain where I'm coming from. Sorry for the distraction.


# Reorganizes solr response into easier to digest objects.
order_facet_fields = solr_response_json.get('responseHeader').get(
'params').get('fl').split(',')
order_facet_fields_joined = solr_response_json.get('responseHeader')\
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've been generally avoiding \

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I think the chaining of get()s would be cleaner like so:

try:
    order_facet_fields_joined = solr_response_json["response_header"]["params"]["fl"]
except KeyError as e:
    # handle error
else:
    # forge ahead

params,
user_uuid=request.user.uuid)
try:
solr_params = generate_solr_params_for_user(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor styling:

solr_params = generate_solr_params_for_user(
        params,
        user_uuid=request.user.uuid
)

@mccalluc
Copy link
Member Author

mccalluc commented Jun 9, 2017

@scottx611x : see if this addresses everything?

@mccalluc
Copy link
Member Author

@scottx611x : I think that one line was the last remaining problem? Let me know if you see anything else.

@mccalluc mccalluc merged commit 363a806 into develop Jun 12, 2017
@mccalluc mccalluc deleted the mccalluc/user-files-next-steps branch June 12, 2017 15:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants