Skip to content
This repository has been archived by the owner on Oct 17, 2020. It is now read-only.

Emit errors through Search API #1000

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Emit errors through Search API #1000

wants to merge 13 commits into from

Conversation

Coteh
Copy link
Collaborator

@Coteh Coteh commented Aug 21, 2020

Fixes #865

Tests not added yet, so this will be in draft until they're added.

Emit errors through search API and add new types for unknown resource and user not provided.

TODO

  • Add test for user not provided
  • Add tests for unknown resource
    • one unknown resource
    • two unknown resources edit: redundant, other two cover it
    • one unknown resource and one known resource
  • Decide whether errors should be emitted as text or as JSON
  • Decide whether to fix two warnings reported by GoLand in handle/search.go (edit: going to skip them, beyond the scope of this PR imo)

@pull-request-size pull-request-size bot added size/L and removed size/M labels Aug 21, 2020
@Coteh Coteh marked this pull request as ready for review August 21, 2020 20:46
@codecov
Copy link

codecov bot commented Aug 21, 2020

Codecov Report

Merging #1000 into master will increase coverage by 0.04%.
The diff coverage is 75.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1000      +/-   ##
==========================================
+ Coverage   52.58%   52.62%   +0.04%     
==========================================
  Files         142      142              
  Lines        3564     3576      +12     
  Branches      168      168              
==========================================
+ Hits         1874     1882       +8     
- Misses       1623     1627       +4     
  Partials       67       67              
Flag Coverage Δ
#golang 72.00% <75.00%> (-0.03%) ⬇️
#typescript 22.40% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
backend/app/usecase/search/search.go 86.95% <75.00%> (-2.37%) ⬇️

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 394a65f...54a7071. Read the comment docs.

Copy link
Member

@arberiii arberiii left a comment

Choose a reason for hiding this comment

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

@Coteh Thank you so much for working in emitting errors!

backend/app/adapter/routing/handle/search.go Outdated Show resolved Hide resolved
ShortLinks []entity.ShortLink
Users []entity.User
}

// ErrUnknownResource represents unknown search resource error.
Copy link
Member

Choose a reason for hiding this comment

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

Maybe we can move this new error.go file. Wdty?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In other usecase files, such as creator.go the error types are embedded within the file. I am not sure what the benefit of having it in a separate file would be, especially since there's only two custom error types at the moment.

backend/app/usecase/search/search.go Outdated Show resolved Hide resolved
ShortLinks []entity.ShortLink
Users []entity.User
}

// ErrUnknownResource represents unknown search resource error.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In other usecase files, such as creator.go the error types are embedded within the file. I am not sure what the benefit of having it in a separate file would be, especially since there's only two custom error types at the moment.

backend/app/usecase/search/search.go Outdated Show resolved Hide resolved
backend/app/usecase/search/search.go Outdated Show resolved Hide resolved
backend/app/usecase/search/search.go Outdated Show resolved Hide resolved
backend/app/usecase/search/search.go Outdated Show resolved Hide resolved
@magicoder10
Copy link
Member

Please hold this PR. We need to discuss what are the expected behaviors.

Comment on lines +51 to +54
// SearchError represents an error with the Search API request.
type SearchError struct {
Message string `json:"message"`
}
Copy link
Member

Choose a reason for hiding this comment

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

I wonder what is this for? Are we going handle it in the frontend?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This will provide information about the search error that occurred. So far, we have "user not provided" and "unknown resource" errors. I think it would make sense to emit these errors in the frontend, even though they may only show up in rare circumstances (e.g. user somehow gets logged out right before they search for something). What do you think?

Comment on lines +215 to +234
func emitSearchError(w http.ResponseWriter, err error) {
var (
code = http.StatusInternalServerError
u search.ErrUserNotProvided
r search.ErrUnknownResource
)
if errors.As(err, &u) {
code = http.StatusUnauthorized
}
if errors.As(err, &r) {
code = http.StatusNotFound
}
errResp, err := json.Marshal(SearchError{
Message: err.Error(),
})
if err != nil {
return
}
http.Error(w, string(errResp), code)
}
Copy link
Member

Choose a reason for hiding this comment

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

Each search error is different in the code. I recommend putting the content of this function back to the code so that the reader can follow the error handling logic. This is an example when abstraction is reducing readability.

// Search finds resources based on specified criteria.
func (s Search) Search(query Query, filter Filter) (Result, error) {
func (s Search) Search(query Query, filter Filter) (ResourceResult, error) {
Copy link
Member

Choose a reason for hiding this comment

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

We are already returning error here. I wonder why are we putting extract error in ResourceResult. Go is making error an interface. By design, the language wants us to return whatever error we get directly.

backend/app/usecase/search/search.go Outdated Show resolved Hide resolved
}()
}

timeout := time.After(s.timeout)
var results []Result
var results []ResourceResult
var resultErr error
Copy link
Member

Choose a reason for hiding this comment

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

This is not needed based on the previous comment.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think this is still needed, because we would like to return only the first error that occurred. What do you think?

switch resource {
case ShortLink:
return s.searchShortLink(query, orderBy, filter)
case User:
return s.searchUser(query, orderBy, filter)
default:
return Result{}, errors.New("unknown resource")
return ResourceResult{}, ErrUnknownResource{}
Copy link
Member

Choose a reason for hiding this comment

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

Let's revert this. Didn't seems to provide value here.

Comment on lines 78 to 108
s.logger.Error(errors.New("user not provided"))
return Result{}, nil
err := ErrUserNotProvided{}
s.logger.Error(err)
Copy link
Member

Choose a reason for hiding this comment

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

Let's directly return error here and log it at the caller.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature] Handle errors of Search API
3 participants