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

Avoid raising exception when ReqMgr2 request is not found #11159

Merged
merged 1 commit into from
May 25, 2022

Conversation

amaltaro
Copy link
Contributor

Fixes #11158

Status

ready

Description

If data for the request name provided cannot be retrieved, return and empty object (dict) to the client. Keeping the server log clean as well.

Is it backward compatible (if not, which system it affects?)

YES

Related PRs

None

External dependencies / deployment changes

None

@amaltaro
Copy link
Contributor Author

Tested in my VM with (and without the detail option)
https://alancc7-cloud1.cern.ch/reqmgr2/data/request?name=blah&detail=true

and this is how the response will look like when request cannot be found:

{"result": []}

@cmsdmwmbot
Copy link

Jenkins results:

  • Python3 Unit tests: succeeded
    • 1 changes in unstable tests
  • Python3 Pylint check: failed
    • 1 warnings and errors that must be fixed
    • 34 comments to review
  • Pylint py3k check: succeeded
  • Pycodestyle check: succeeded
    • 2 comments to review

Details at https://cmssdt.cern.ch/dmwm-jenkins/view/All/job/DMWM-WMCore-PR-test/13247/artifact/artifacts/PullRequestReport.html

@amaltaro amaltaro requested a review from vkuznet May 24, 2022 19:27
Copy link
Contributor

@vkuznet vkuznet left a comment

Choose a reason for hiding this comment

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

@amaltaro , there are several issues with the code:

  • line 80 returns a dict, while line 82 returns a list. Inconsistent data-type from the same API is a bad practice since it forces clients to handle (parse) different data-types.
  • on the same line you change result local variable by re-assigning to it different values, instead it is better to just return this alue
  • there is no docstring for this function, and since you are touching it , then it is better to add a docstring
  • I suggest to add comment about data-type of the doc returned by getDoc API.
  • if result = self.couchDB.getDoc(requestName) is a dict then it is better to use result.get('RequestName', ...) call where you should supply default (proper) value (data-type), e.g. result.get('RequestName', "") if RequestName is a string (I have not idea what should be returned, a string or some sort of the object).
  • in elif result it is unclear a type of result, someone can think it is a boolean or empty list or empty dict, at least you should add a proper comment over there or better check results data-type and value.

@amaltaro
Copy link
Contributor Author

Thanks for a prompt review! See below some follow up to the points you raised.

line 80 returns a dict, while line 82 returns a list. Inconsistent data-type from the same API is a bad practice since it forces clients to handle (parse) different data-types.

I understand and I also agree with this. However, I am not changing it here because it might affect clients that are already consuming such information and the present format for years.

Other than the comment below, I made further modifications and it's ready for another review. Note, however, that this PR is meant to only fix the exception raised on the server side.

@amaltaro amaltaro requested a review from vkuznet May 24, 2022 20:01
@cmsdmwmbot
Copy link

Jenkins results:

  • Python3 Unit tests: succeeded
  • Python3 Pylint check: failed
    • 1 warnings and errors that must be fixed
    • 34 comments to review
  • Pylint py3k check: succeeded
  • Pycodestyle check: succeeded
    • 2 comments to review

Details at https://cmssdt.cern.ch/dmwm-jenkins/view/All/job/DMWM-WMCore-PR-test/13249/artifact/artifacts/PullRequestReport.html

Copy link
Contributor

@vkuznet vkuznet left a comment

Choose a reason for hiding this comment

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

Alan, the changes are fine but you can still improve things by changing this block:

        if detail:
            result.pop('_attachments', None)
            result.pop('_rev', None)
            result = {result['RequestName']: result}
        else:
            result = [result['RequestName']]
        return result

to

        if detail:
            result.pop('_attachments', None)
            result.pop('_rev', None)
            return {result['RequestName']: result}
        return[result['RequestName']]

In other words, you don't need to create redundant local variable, assign to it results and then return it. Less code, no copying, no re-assignment, less if/else block.

some of Valentins suggestions

Valentins return suggestion
@amaltaro
Copy link
Contributor Author

Thanks @vkuznet . I have applied the changes you suggested, but in the end it's a tradeoff of having multiple return statements spread in the method versus leaving the final return to the end of the method.
Code has been updated and squashed, please have a final look. Thanks

@amaltaro amaltaro requested a review from vkuznet May 25, 2022 14:31
@cmsdmwmbot
Copy link

Jenkins results:

  • Python3 Unit tests: succeeded
    • 1 tests deleted
    • 2 changes in unstable tests
  • Python3 Pylint check: failed
    • 1 warnings and errors that must be fixed
    • 34 comments to review
  • Pylint py3k check: succeeded
  • Pycodestyle check: succeeded
    • 2 comments to review

Details at https://cmssdt.cern.ch/dmwm-jenkins/view/All/job/DMWM-WMCore-PR-test/13250/artifact/artifacts/PullRequestReport.html

@amaltaro amaltaro merged commit f2aef9c into dmwm:master May 25, 2022
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.

KeyError exception in RequestDBReader module
3 participants