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 unbound var in search view #5794

Merged
merged 2 commits into from Jun 12, 2019
Merged

Fix unbound var in search view #5794

merged 2 commits into from Jun 12, 2019

Conversation

@stsewd
Copy link
Member

@stsewd stsewd commented Jun 12, 2019

search can end up unbound if there isn't a valid facet

Fix https://sentry.io/organizations/read-the-docs/issues/1054512234/?project=148442&query=is%3Aunresolved

@@ -105,7 +100,7 @@ def elastic_search(request, project_slug=None):

# Make sure our selected facets are displayed even when they return 0 results
for avail_facet in ALL_FACETS:
value = getattr(user_input, avail_facet)
value = getattr(user_input, avail_facet, None)
Copy link
Member Author

@stsewd stsewd Jun 12, 2019

Choose a reason for hiding this comment

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

if a default isn't given to getattr it raises an exception.

Loading


results = ''
results = None
Copy link
Member Author

@stsewd stsewd Jun 12, 2019

Choose a reason for hiding this comment

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

This feels more like an object than an empty string

Loading

@stsewd stsewd requested review from ericholscher and Jun 12, 2019
Copy link
Member

@humitos humitos left a comment

Looks good to me.

I left just a question about the what to do when the user_input.type is not what we are expecting.

Loading

)

search = search_facets[user_input.type](
query=user_input.query, user=request.user, **kwargs
Copy link
Member

@humitos humitos Jun 12, 2019

Choose a reason for hiding this comment

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

The solution with defaultdict is more readable to me, I like it. Although, there is a new logic hidden: if the type does not exist (for any reason) we are going to return ProjectSearch results. Is that OK? would be better to just return no results at all?

Loading

Copy link
Member

@humitos humitos Jun 12, 2019

Choose a reason for hiding this comment

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

We may want to add another condition next to the user_input.query

... and (user_input.type in search_facets):

and remove the lambda from the defaultdict.

Loading

Copy link
Member Author

@stsewd stsewd Jun 12, 2019

Choose a reason for hiding this comment

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

Loading

Copy link
Member

@humitos humitos Jun 12, 2019

Choose a reason for hiding this comment

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

👍

It seems we have the default set in multiples places then. I think we could just have only one.

Loading

@stsewd stsewd merged commit de0e916 into readthedocs:master Jun 12, 2019
1 check passed
Loading
@stsewd stsewd deleted the fix-unbound-var branch Jun 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants