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

Fix to get_schema(s) to use URL prefixed with slash for vapp. #283

Merged
merged 5 commits into from
Sep 8, 2023

Conversation

dmichaels-harvard
Copy link
Contributor

@dmichaels-harvard dmichaels-harvard commented Sep 8, 2023

  • For the vapp (portal_vapp) case, the URL for ff_utils.get_schema(s) needs to be prefixed with a slash; maybe true in general but nervous about changing that now for fear of wider breakage.
  • Also, the response from vapp.get returns a webtest.response.TestResponse, which has a json property which is an object rather than a function; handling this in ff_utils.get_response_json.

Copy link
Collaborator

@netsettler netsettler left a comment

Choose a reason for hiding this comment

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

You can ignore my whiny comments, which are not blocking but I just wanted to say. This is fine.

@@ -1022,7 +1022,7 @@ def get_schemas(key=None, ff_env: Optional[str] = None, *, allow_abstract: bool
base_url = 'profiles/'
add_on = 'frame=raw'
if portal_vapp:
full_url = f"{base_url}?{add_on}"
full_url = f"/{base_url}?{add_on}"
Copy link
Collaborator

Choose a reason for hiding this comment

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

i guess this is most conservative. if / is ok in get_metadata, then maybe put the / in the initialization of base_url. But either is OK and this is safest, I guess.

res_json = res.json()
if isinstance(res, VirtualAppResponse):
res_json = res.json
else:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Again this is most conservative but I wonder if this should be type-checking, too. I guess let's go with this for now as most minimal change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You mean type checking the json property?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh, I was just wondering if we should do a plain else or another if with another type. But it previously just did .json() with no test, so this will be most compatible. I wouldn't have designed fresh code that way if I knew multiple types were in play. It preferences one default over another when you really don't konw. The presence of the try: around it is an apology for just taking a guess and hopes the damage won't be too great if it guesses wrong.

@coveralls
Copy link

Pull Request Test Coverage Report for Build 6125878108

  • 6 of 7 (85.71%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.003%) to 77.782%

Changes Missing Coverage Covered Lines Changed/Added Lines %
dcicutils/ff_utils.py 5 6 83.33%
Totals Coverage Status
Change from base Build 6113817551: -0.003%
Covered Lines: 8255
Relevant Lines: 10613

💛 - Coveralls

@dmichaels-harvard dmichaels-harvard merged commit 989593d into master Sep 8, 2023
4 checks passed
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.

3 participants