When calling List or Count with change.FilterAll, omit the "states" argument from the GraphQL query, rather than using an empty list (). This is simpler and produces more consistent results.¹ ¹ https://github.community/t5/GitHub-API-Development-and/Inconsistency-of-empty-state-filter-between-Repository-issues/m-p/30659#M2888
This produces more accurate results and is consistent with similar code elsewhere. This change also improves handling of other PullRequestReviewState values.
The responsibility of marking changes as read is being moved from the service level to the changes application. This approach scales better. It makes it possible to use the changes service for other internal purposes. For example, it's being used internally as part of implementing a Gerrit notification v2 service. It also means the changes application can decide to mark a thread as read when the user scrolls down and sees the new content, instead of right away on page load. In general, it's easier for the changes application to know (with more certainty) when a change has been read by a user.
Their previous arrangement made it so that the PR review case completely shadowed the PR review comment case, since strings.HasPrefix(cr.ID, "r") is always true whenever strings.HasPrefix(cr.ID, "rc") is true.
Previously, GitHub itself did not support leaving reactions on Pull Request reviews. It was only possible to leave reactions on normal comments and inline review comments. They've added that feature now, so this change implements it accordingly in this package. Reference: https://developer.github.com/v4/changelog/2019-01-11-schema-changes/.
This helps with displaying large PRs that have over 100 timeline items (e.g., https://github.com/neelance/go/pull/7). The implementation is based the similar issues service ListTimeline, see https://github.com/shurcooL/issues/commit/4081aa59e957752abbfc6b6fdab72c3bbc1c1dec.
This is more robust. It also removes the need to talk to real GitHub API while creating a new service, which is undesirable during testing. Analogous to https://github.com/shurcooL/issues/commit/adf13e46e3d966ef14ee08722b56b823cf5c3f3b.
Previously, it panicked. Now that I have a better how to deal with it, add a comment describing the state. For now, skip such reviews. In the future, can display them with a pending/draft style.
It can't be set in Go 1.10 due to reflect changes. Also switch from githubqlActor to githubqlUser because RequestedReviewer union is known to be User or Team, so Actor interface is unnecessarily broad. References: - https://tip.golang.org/doc/go1.10#reflect - https://developer.github.com/v4/union/requestedreviewer/ - https://developer.github.com/v4/interface/actor/
Detect ghost actors/users via them missing entirely, rather than checking for zero DatabaseID. This is consistent with how GitHub GraphQL returns them at this time. Fix minor miscounting issue in reactions method. Remove unneeded error return parameter from reactions method. These changes help keep the code more consistent with issues/githubapi package.