Most of the time, the table row for rawhide is empty, showing no builds. Sometimes this is semi-correct if no build was done since the Fedora N branch point, but even then the last tagged build from Fedora N-1 should be shown, since there's not no build available, just not one that was built since the branch point.
At other times, it shows an outdated build for rawhide - if a build for Fedora N was successful before the Fedora N mass rebuild, the table will continue to show the old build and not the one from the mass rebuild.
This is probably because only builds that went through bodhi are shown, but successful builds from mass rebuilds do not go through bodhi at all.
Example for a package where an outdated build is listed for rawhide: https://src.fedoraproject.org/rpms/elementary-calendar
Example for a package where no build for rawhide is listed after the mass rebuild: https://src.fedoraproject.org/rpms/python-blinker
The logic is to query bodhi for the build and if nothing is found in bodhi then it queries mdapi for that package.
Well .... then either mdapi has bad data or the query doesn't work? I have never used mdapi before, how do I check?
The whole logic is at: https://pagure.io/pagure-dist-git/blob/master/f/pagure_distgit/plugin.py#_388
I think I found the issue.
https://pagure.io/pagure-dist-git/blob/master/f/pagure_distgit/plugin.py#_491
mdapi_url = "https://mdapi.fedoraproject.org/%s/srcpkg/%s" % ( release.lower(), repo.name, )
This returns an HTTP 400 error code for "f34" but HTTP 200 for "rawhide", "f32", and "f33", so mdapi only supports naming rawhide "rawhide", and not by its "fxx" value.
There's also no error logging if this request fails, so this is why it was never noticed I guess :)
I think this issue can be closed, since the backend data source has been changed with the last release.
Metadata Update from @decathorpe: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)