We came across this issue:
https://pagure.io/fedora-infrastructure/issue/6290
It seems that @robert has two branches that he requested, the first being "epel7" and the second being "el6". He was able to write to "epel7" but not "el6". What I think happened is that fedrepo-req-admin processed the "epel7" branch request first, this triggered Pagure over dist-git to regenerate it's ACLs on the "libburn1" project. These ACLs are determined based on the results of a query to PDC. This query is then cached for 600 seconds. Within seconds after the first request, fedrepo-req-admin processed the "el6" branch request, which again, triggered Pagure over dist-git to regenerate it's ACLs on the project. This time, it used the cached query from seconds ago, omitting the "el6" branch in PDC.
We came across this issue:
https://pagure.io/fedora-infrastructure/issue/6290
It seems that @robert has two branches that he requested, the first being "epel7" and the second being "el6". He was able to write to "epel7" but not "el6". What I think happened is that
fedrepo-req-adminprocessed the "epel7" branch request first, this triggered Pagure over dist-git to regenerate it's ACLs on the "libburn1" project. These ACLs are determined based on the results of a query to PDC. This query is then cached for 600 seconds. Within seconds after the first request,fedrepo-req-adminprocessed the "el6" branch request, which again, triggered Pagure over dist-git to regenerate it's ACLs on the project. This time, it used the cached query from seconds ago, omitting the "el6" branch in PDC.This PR simply removes the caching.