Learn more about these different git repos.
Other Git URLs
https://pagure.io/flock/issue/20 doesn't seem to have a corresponding file in the issues git repo. Why is this?
I am seeing it:
git grep 'Python-SIG' a67e2b54f3f641a8835a9c34dbed02e5: "title": "[Community Workshop] Python-SIG meetup",
but it seems into only appeared when you added a tag to it:
git log a67e2b54f3f641a8835a9c34dbed02e5 commit 180615fa4bcbb090a86e96c30c54da116fc0db77 Author: pagure <pagure> Date: Mon Jul 2 13:07:24 2018 +0000 Updated issue a67e2b54f3f641a8835a9c34dbed02e5: [Community Workshop] Python-SIG meetup
Basically, refreshing the tickets/PR metadata git repo is a slow operation that happens quite a lot. One of the way we improved the UX on pagure was to split slow and fast operations into different queues so the fast ones are processed quickly and the slow ones, not affecting the UX/UI are done as they can in the background. Updating the metadata git repos is on the slow queue. So depending on the load of this queue, it can take a little bit of time before it gets updated. This could be one reason.
Another reason is simply that they may have been a restart or something at the time the ticket got created and the message got missed in the queue :-s (Or it ran into this too many files open error we've seen recently and have not yet fixed which prevented the task from being completed correctly).
too many files open
Unfortunately, I don't think we have enough information to debug this issue, so I'll close as 'Insufficient Data' but I'll try to keep an eye on this.
If you see this again in the future, please let us know :)
Metadata Update from @pingou: - Issue close_status updated to: Insufficient data
Thanks for the update. One question: From the answer, it sounds like the metadata repos are copies and not the master records. Is this correct?
That would be correct, the UI is built from what is in the DB, the metadata repo should reflect what is in the DB (modulo some time to catch up with the queue and bugs :().
One reason the git repos aren't the source of truth is that searching, filtering based on text file is hard. It would mean creating on-disk indexes of all sorts and at the end we would end up with some sort of custom-built database system.
This makes sense, but if the repos aren't reasonably gurantees it seems to highly limit their usefulness. I presume, as I haven't looked but need to, that all the same data could be harvested by the API and it actually hits the database.
I use the repo for offline access mostly and to mirror/migrate tickets/PRs. I don't know which use-case you had for it :)
I wanted to use it as a source of structured files for issues to import into other tools. This is why I noticed the missing file, my import didn't have everything I needed.
Note that there is a button in the settings allowing to re-generate the json files for all tickets, this is a slow process though, but can be helpful :)
Log in to comment on this ticket.