request: API does not always include who on review entries #3857
Comments
|
Just looked briefly at it but could be similar to what I fixed recently for @lchiquitto. Have a look at So could be that it is already fixed but of course still wrong for old requests (maybe we can fix it with a migration?) |
|
Hmm, looking at the changes to test case it does not include @@ -108,8 +108,8 @@ def test_parse_bigger
<state name="review" who="Iggy" when="2012-11-07T21:13:12">
<comment>No comment</comment>
</state>
- <review state="new" by_user="adrian"/>
- <review state="new" by_group="test_group"/>
+ <review state="new" when="2017-09-01T09:11:11" by_user="adrian"/>
+ <review state="new" when="2017-09-01T09:11:11" by_group="test_group"/>
<review state="accepted" when="2012-11-07T21:13:12" who="tom" by_user="tom">
<comment>review1</comment>
</review>So I would imagine that bit is not fixed since it seems the primary target of that issue was the |
jberry-suse
changed the title
jberry-suse
changed the title
|
reviews in state "new" may indeed not have a who, when these are default reviewers. Do you have an example where a who is missing and the state got changed? |
|
I included examples of reviews that were not automatically added (like reviews), but were added by someone. <review state="new" when="2017-06-23T13:51:04" by_project="openSUSE:Leap:42.3:Staging:D">That review is set by the staging tools and therefore was performed by a user. In the other couple hundred thousand requests I processed it was there. |
Issue/Feature description
The tool I am creating to parse historical request data for metrics has revealed some seemingly inconsistent or broken data being returned via the API. From the request that I have analyzed it seems to occur when a review is either
obsoletedor leftnewwhile request was placed in a final state such asaccepted. Thowhovalues can be seen in the web interface and the history entries (which is likely what the web interface represents) and clearly there were performed by a someone, but seem to be arbitrarily missing in the returned data.Expected result
The
whowould always be present.How to Reproduce
osc api '/request/$reqid'for a request effected by this issueFurther information
Some examples (only showing relevant parts of request XML):
One can see that
staging-botopened the review since it accepted thefactory-stagingreview, but interestingly I see no way thatstaging-botwould have opened thefactory-stagingreview since that is done automatically since the project includesfactory-stagingas a reviewer in the config.Similarly this can be seen when a review is
obsoletedsince the project was removed.Again, somehow the
whois no longer present although it can be inferred from thefactory-stagingaccept entrywho.Also note that I cannot re-create the loss of
whoby creating a fresh request and walking through these cases, so there is likely more to it.As an aside, using
<history>to indicate an event that takes place more recently than the primary<review>tag is a bit backwards although I can see what it is trying to convey.So far I have found such occurrences in the following requests and analyzed a few to notice these cases, but that is not to say this is the complete set of cases. I would be rather curious to know what sort of code could cause this type of problem. I will likely try to workaround these cases since the
whocan be inferred since these are "related" requests due to being part staging workflow, but really this should be resolved. If I find that some are missing more I may just have to ignore them for the time being.The text was updated successfully, but these errors were encountered: