New smart API to list issues#2534
Conversation
vrigal
force-pushed
the
api-list-issues
branch
from
276e8a2 to
6a2042c
Compare
|
I noticed the same combination of (analyzer, level, check, message) may be reported multiple times per file, which would lead to inconsistent returned values. For example, a new issues could be reported as known (if a similar issue is known on this file) or an issue could be returned as both unresolved and closed (in case there are multiple similar issues on a file, and only one has been closed). I think we should keep this endpoint KISS, and handle such edge cases in the bot. |
vrigal
force-pushed
the
api-list-issues
branch
from
6a2042c to
80c1006
Compare
vrigal
force-pushed
the
api-list-issues
branch
from
45d027f to
e068704
Compare
La0
left a comment
La0
left a comment
There was a problem hiding this comment.
A few comments to address as discussed together.
Then we'll run it on a local prod dump, and can probably ship to testing as it adds new endpoints.
| self.diff.issue_links.annotate( | ||
| known=Exists( | ||
| IssueLink.objects.filter( | ||
| revision__base_repository__slug="mozilla-central", |
There was a problem hiding this comment.
You can use the curent diff base repository id to make the query generic & faster (one less join)
| revision__base_repository__slug="mozilla-central", | |
| revision__base_repository_id=self.diff.revision.base_repository_id, |
There was a problem hiding this comment.
revision__base_repository_id=self.diff.revision.base_repository_id do includes all issues from all diffs with the base repository. I suppose it should match revision__head_repository_id instead ?
|
You will also need to serialize the This does not invalidate the fact that a 400 should be raised when it's not present in these cases |
vrigal
force-pushed
the
api-list-issues
branch
from
f77168b to
700f709
Compare
2 participants
Based on #2530(merged)Closes #2533
All issues that are not returned as known/closed/unresolved can be considered as new.