Skip to content

Conversation

smacker
Copy link
Contributor

@smacker smacker commented Nov 15, 2018

Fix #280 but differently from the description in the issue.

Working on the original proposal I realized it would require to complicate interfaces a lot.
Poster must return remoteID, add new methods.
Storage interfaces become much more complicated due to the need for transactions across different storages.

Here is different proposal implementation:

  1. Poster should implement "safe" mode if it's applicable
  2. I introduced new status for events that reflects posting was started but not finished. In such case server uses "safe" mode.

There are few more fixes:

  1. Add sleep when posting many comments or we hit the same error (was submitted too quickly)
  2. Transport to fix (unify) non-standard errors from review endpoint to normal once. So when we get an error we can actually see the response from GH and log it. (currently such errors logged as empty structures)

@@ -111,7 +115,7 @@ func (s *Server) HandleEvent(ctx context.Context, e lookout.Event) error {
}

// HandleReview sends request to analyzers concurrently
func (s *Server) HandleReview(ctx context.Context, e *lookout.ReviewEvent) error {
func (s *Server) HandleReview(ctx context.Context, e *lookout.ReviewEvent, safePosting bool) error {

Choose a reason for hiding this comment

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

duplicate of server/server.go:166-210 (dupl)

If you have feedback about this comment, please, tell us.

@carlosms
Copy link
Contributor

Looks good to me.

On one hand seems a bit complex for an uncommon problem where the worst that can happen is having duplicated, but valid, comments. On the other hand, since this should only happen very rarely, I guess the added complexity does not affect the common code path and it's ok to handle this corner case in the proper way.

I'm not sure about merging comments. If they come from different analyzers, having them as independent comments allows to have 2 conversation threads, or resolve one of them as a bad suggestion but keep discussing the other one.

Maybe it would make sense to merge comments that come only from the same analyzer.

@smacker
Copy link
Contributor Author

smacker commented Nov 16, 2018

the added complexity does not affect the common code path

true. The only change for normal code path - writing one more status to DB.

Maybe it would make sense to merge comments that come only from the same analyzer.

good point!

@smacker smacker changed the title [WIP] Better review comments Better review comments Nov 19, 2018
@smacker smacker requested a review from carlosms November 19, 2018 17:16
Signed-off-by: Maxim Sukharev <maxim@sourced.tech>
Signed-off-by: Maxim Sukharev <maxim@sourced.tech>
Signed-off-by: Maxim Sukharev <maxim@sourced.tech>
Signed-off-by: Maxim Sukharev <maxim@sourced.tech>
Signed-off-by: Maxim Sukharev <maxim@sourced.tech>
Signed-off-by: Maxim Sukharev <maxim@sourced.tech>
@smacker
Copy link
Contributor Author

smacker commented Nov 27, 2018

ping @carlosms (rebased on master)

Copy link
Contributor

@carlosms carlosms left a comment

Choose a reason for hiding this comment

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

👍

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.

Handle failure during posting comments
2 participants