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

[MM-350] Fix issue in create issue modal and attach issue modal #761

Merged
merged 2 commits into from
Jul 13, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions server/plugin/api.go
Original file line number Diff line number Diff line change
Expand Up @@ -806,6 +806,7 @@ func (p *Plugin) searchIssues(c *UserContext, w http.ResponseWriter, r *http.Req
result, _, err := githubClient.Search.Issues(c.Ctx, query, &github.SearchOptions{})
if err != nil {
c.Log.WithError(err).With(logger.LogContext{"query": query}).Warnf("Failed to search for issues")
p.writeJSON(w, make([]*github.Issue, 0))
Copy link
Contributor

Choose a reason for hiding this comment

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

There are a lot of other endpoints that don't return valid JSON in the error case. Should we update the webapp to not expect JSON if the status code indicates an error?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hanzei We were thinking of updating the plugin API response for each API where we are not returning anything in case we get any errors from the GitHub API.
For example: At this line, we can return an error something like p.writeAPIError(w, &APIErrorResponse{Message: "Failed to search for issues", StatusCode: http.StatusInternalServerError}) and handle the error similarly at the webapp side.
What are your thoughts on this?

Copy link
Contributor

Choose a reason for hiding this comment

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

If githubClient.Search.Issues finds nothing that matches the search, does it return an error?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we put an invalid organisation or an organisation we don't have access to, we get an error, and it gets rendered as shown in the screenshot below. 
image

But it doesn't return any errors when we search for an issue with a random input term (empty or an organisation we have access to).

Copy link
Contributor

Choose a reason for hiding this comment

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

We def want to avoid showing this Unexpected end of JSON input error in all cases

Copy link
Contributor

Choose a reason for hiding this comment

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

I see the value in consistently returning a JSON payload for calls the webapp makes. Should this be addressed holistically as part of this PR?

I suggest we update the signature of API methods like searchIssue from (c *UserContext, w http.ResponseWriter, r *http.Request) to (c *UserContext, r *http.Request) (any, int) and let a wrapper handle deal with writing the returned payload and status code. That way we ensure that all of these endpoint return valid JSON.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hanzei Should we create a new issue to update the structure of the APIs and merge this PR to resolve the issue mentioned in the description?
Also, there were two ways we were thinking of fixing the response of the API:

  1. Create a wrapper and update API methods from (c *UserContext, w http.ResponseWriter, r *http.Request) to (c *UserContext, r *http.Request) (any,  int) as stated by you. We can also include a field of error with the data and the status code. In the wrapper, we can check for errors and data. If the error is returned, we can return p.writeAPIError(w, &APIErrorResponse{Message: "ErrorMessage", StatusCode: statusCode}) and handle similarly on webapp and if there is no error we can return data or an empty list if data is also empty.
  2. In this way, we can directly update the API to simply return p.writeAPIError(w, &APIErrorResponse{Message: "ErrorMessage", StatusCode: statusCode}) in case of error. We can avoid making a wrapper in this case.

What are your thoughts on this? Please let me know if I missed something here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Either one sounds good to me. Which one is less complicated in your opinion @ayusht2810? Have you tried implemented one of them to see if it fits well?

Copy link
Contributor

Choose a reason for hiding this comment

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

@mickmister We are thinking to proceed with the second method.
we can do this it in this PR or we can create a new PR and merge this so that the issue is fixed

Copy link
Contributor

Choose a reason for hiding this comment

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

@Kshitij-Katiyar Sure separate PR sounds good 👍

return
}

Expand Down
4 changes: 4 additions & 0 deletions webapp/src/actions/index.ts
Original file line number Diff line number Diff line change
Expand Up @@ -76,6 +76,10 @@ export function getRepos() {
try {
data = await Client.getRepositories();
} catch (error) {
dispatch({
type: ActionTypes.RECEIVED_REPOSITORIES,
data: [],
});
return {error: data};
}

Expand Down
Loading