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

request: API XML result is rather inconsistent and poorly structured #3898

jberry-suse opened this issue Sep 22, 2017 · 0 comments


Copy link

commented Sep 22, 2017

Having written extensive processing of requests for generating detailed metrics and re-creating project level staging state based on multiple requests I have run into quite some issues with the structure of the data and a few clear bugs.

  • #3857 request: API does not always include who on review entries
  • #3858 request: state when date is incorrect
  • #3897 request: 446602 does not include <history> element for <priority> change

Based on the structure I am going to assume this organically grew into this structure as it makes little sense to design it like this. The disconnect between <history> and <review> or <priority> is rather painful and repeating data rather than providing the other value that would be useful is also silly and frustrating.

One would expect when passing withfullhistory=1 that it would be clear to re-create simple things like when and who added a review and when and who changed its state, but it really is not.

When a review is first added it will look something like:

  <review state="new" when="2017-09-22T19:25:18" who="jberry" by_user="jberry_factory">
    <comment>staging review</comment>

Note that jberry added a review for jberry_factory. After jberry_factory accepts the review the results looks like the following.

  <review state="accepted" when="2017-09-22T19:23:56" who="jberry_factory" by_user="jberry_factory">
    <history who="jberry_factory" when="2017-09-22T19:24:37">
      <description>Review got accepted</description>

Not only is <history> used to denote something in the future of the parent <review> element, but for only the current state and person who last changed can be seen. It is no longer possible to see that the review was added by jberry. This is rather useless and utterly confusing when one considers that all the values on the <review> tag represent the current state except the when which represents the original state. What!?

If one looks at the <history> elements, one can find the relevant data, but there is no clear data that indicates this was for the jberry_factory review.

  <history who="jberry" when="2017-09-22T19:23:56">
    <description>Request got a new review request</description>
    <comment>staging review</comment>

Unfortunately, short of guessing the when field is the only one that may match. Depending on how long OBS took to process the data may not be identical and I have found can vary by a fair bit. Obviously, multiple reviews could have been added simultaneously or close enough to mess this up. One would expect that withhistory, much less withfullhistory would actually contain a real history instead of a sub element that contains duplicate information that is already contained on the parent element in a very wacky mix.

Multiple state changes where a request is reviewed multiple times is even less trivial to walk since any comments are no longer unique enough to parse. This really does not need to be this way.

Walking <priority> changes is just as bad, since one has to parse the <history> description text to see the state changes.

One can only imagine the level of absurd workarounds that I have implemented to extract something reasonable from this data. This should really be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.