If this is intentional, why the item and the type are String in the messages?

https://apps.fedoraproject.org/datagrepper/id?id=2017-cb924c7c-4467-4af8-a779-481614721436&is_raw=true&size=extra-large

It seems to me we should make it consistent.

Can you provide a datagrepper link for the message in comment 0, so that we can see the full message?

I might have misunderstood - is the data in comment 0 a result pulled out of resultsdb through its API? In that case, again, a link would be good.

The first one comes from the internal instance. The command I'm using is

http https://<internal resultsdb url>/api/v2.0/results/892591

I can't give you a Fedora one as the Fedora instance is down at the moment, :-)

Just so you know - this is intentional, and right. in ResultsDB, all the extra data can contain multiple values. Item and Type are no exception. If I should guess, the author of the code which sends Fedmsgs either did not know that, or decided to act on the convention, that most (if not all) of resultsdb results in Fedora only have one item and type value.

When getting the data through api, all the extra data (key-value sotre, however you want to be callint it) have the value of list(str) type by design.

Thanks for your explanation, @jskladan. You could close this issue.

Actually, it still does not look right to me. If there are multiple items and types, it seems like we only publish the last item and the last type in the message.

https://pagure.io/taskotron/resultsdb/blob/develop/f/resultsdb/messaging.py#_137

@mjia I am not at all opposed to changing this, but I/we do not consume the messages, and I'm not sure how to
1) find out who does
2) do the change without breaking those people's deployments in a nasty way

As I said - with our use-cases, we always only ever have one item/type per result, so in an obscure way, this is a "non-issue", but I absolutely understand the confusion/reason for you asking. On top of that, it might make sense to change the messages, but I don't feel comfortable deciding this.

@ralph what's your take on this?

Or we could change this the other way round and make extra data fields a single value only. I'm not sure if somebody intends to use this functionality and makes consuming it more difficult. But it's true that specifying two items tested in a single result might have some uses. The question is if it's worth it.

@kparal No.