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

Return 404 for nonexistent search components #11532 #11533

Merged
merged 1 commit into from
Oct 19, 2024

Conversation

jacobtylerwalls
Copy link
Member

Types of changes

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of Change

Respond with a 404 view instead of an unhandled 500 exception for requests to the search_home route with a nonexistent search-view param.

Issues Solved

Closes #11532

Checklist

  • I targeted one of these branches:
    • dev/8.0.x (under development): features, bugfixes not covered below
    • dev/7.6.x (main support): regressions, crashing bugs, security issues, major bugs in new features
    • dev/6.2.x (extended support): major security issues, data loss issues
  • I added a changelog in arches/releases
  • I submitted a PR to arches-docs (if appropriate)
  • Unit tests pass locally with my changes
  • I added tests that prove my fix is effective or that my feature works
  • My test fails on the target branch

Ticket Background

Further comments

We can target 8 instead if this doesn't qualify as a "major" bug in a new feature, but would be nice since the LTS was recent to avoid issuing 500s in people's server logs if we can.

@jacobtylerwalls jacobtylerwalls changed the base branch from master to dev/7.6.x October 8, 2024 18:51
Copy link
Member

@whatisgalen whatisgalen left a comment

Choose a reason for hiding this comment

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

@jacobtylerwalls this seems like a good change on its face especially from the point of view of the backend. However with being more concise about the type of error code (404 vs 500) the http404 seems to bypass the error handling in search_results and the end user is no longer in Arches search but is now sort of stranded on whatever the 404 page is. I don't actually think that should be the UX because there's nothing to tell you what went wrong in a prod deployment. I also think that maybe the 404 should be reserved for something more like a non-existent url path as opposed to a query parameter that leads to a non-existent thing in the database. @apeters I think you likely have thoughts on this as well.

@apeters
Copy link
Member

apeters commented Oct 18, 2024

@whatisgalen to me this is really like submitting an incorrect route to Arches. You're asking for a base page layout that doesn't exist. I think throwing an http404 makes sense in that case.

@apeters apeters self-assigned this Oct 18, 2024
@apeters apeters self-requested a review October 18, 2024 23:05
Copy link
Member

@apeters apeters left a comment

Choose a reason for hiding this comment

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

I'll approve this once the merge conflicts are fixed

@jacobtylerwalls jacobtylerwalls force-pushed the jtw/404-for-unknown-search-component branch from 8534307 to ae17f5b Compare October 18, 2024 23:52
@apeters apeters merged commit 4d8e7a2 into dev/7.6.x Oct 19, 2024
7 checks passed
@apeters apeters deleted the jtw/404-for-unknown-search-component branch October 19, 2024 02:16
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.

search_home route raises AttributeError for missing search components
3 participants