Github API returning invalid label ids

[baby-gnu]

Hello.

I'm happily using forge since several months and found an issue today with one repository:

Pulling saltstack-formulas/openssh-formula...done
Storing saltstack-formulas/openssh-formula...
error in process filter: peculiar error: "FOREIGN KEY constraint failed" [2 times]

It's working fine with other repositories like systemd-formula.

Here are few repositories wit the same error:

• template-formula
• telegraf-formula

[tarsius]

The problem appears to be data corruption on Github's side. There appear to be two labels named bug even though bug appears to be the primary key (or at least some sort of "unique" filter is used on that column). The issue 176 has one label with the id MDU6TGFiZWwxNjA2NzQzMTU2 and name bug, but that label is not included in the list of "all" labels.

(ghub--graphql-vacuum
 '(query
   (repository
    [(owner $owner String!)
     (name  $name  String!)]
    (issue [(number 176)]
           (labels [(:edges t)
                    (:singular label id)]
                   id
                   name))
    ;; We cannot get information about the label by the id
    ;; MDU6TGFiZWwxNjA2NzQzMTU2 because the API expects the
    ;; name instead of the id. When we use its name "bug", then
    ;; we get information about another label by the same name.
    (label ;; [(id "MDU6TGFiZWwxNjA2NzQzMTU2")]
           [(name "bug")]
           id
           name)
    ;; This should but does not include the label with the
    ;; id MDU6TGFiZWwxNjA2NzQzMTU2.
    (labels [(:edges t)
             (:singular label id)]
            id
            name)))
 '((owner . "saltstack-formulas")
   (name  . "openssh-formula"))
 (lambda (data) (pp-display-expression data "*Pp*")))

(data
 (repository
  (issue
   (labels
    ((id . "MDU6TGFiZWwxNjA2NzQzMTU2")
     (name . "bug"))))
  (label
   (id . "MDU6TGFiZWw0MzI0NTg3MQ==")
   (name . "bug"))
  (labels
   ((id . "MDU6TGFiZWw0MzI0NTg3MQ==")
    (name . "bug"))
   ((id . "MDU6TGFiZWw0MzI0NTg3Mg==")
    (name . "duplicate"))
   ((id . "MDU6TGFiZWw0MzI0NTg3Mw==")
    (name . "enhancement"))
   ((id . "MDU6TGFiZWw0MzI0NTg3NA==")
    (name . "invalid"))
   ((id . "MDU6TGFiZWw0MzI0NTg3NQ==")
    (name . "question"))
   ((id . "MDU6TGFiZWw0MzI0NTg3Ng==")
    (name . "wontfix"))
   ((id . "MDU6TGFiZWwxMjMwMzg2OTE4")
    (name . "bump:major"))
   ((id . "MDU6TGFiZWwxMjMwMzg3MzA0")
    (name . "bump:minor"))
   ((id . "MDU6TGFiZWwxMjMwMzg3NjEx")
    (name . "bump:patch"))
   ((id . "MDU6TGFiZWwxNTUzNDUwMTU2")
    (name . "released"))
   ((id . "MDU6TGFiZWwyMDkwNzA1Mjk3")
    (name . "dependencies")))))

There isn't really anything we can to but to ask Github to fix the corrupted data.

[baby-gnu]

Thanks a lot for the debug @tarsius.

I found that the issue saltstack-formulas/openssh-formula#176 label bug as an URL pointing to another repository https://github.com/saltstack-formulas/.github/labels/bug. I will see with the team if someone understand what's happening.

Thanks.

[baby-gnu]

I found that the issue saltstack-formulas/openssh-formula#176 label bug as an URL pointing to another repository https://github.com/saltstack-formulas/.github/labels/bug. I will see with the team if someone understand what's happening.

In Github, you can group all your common labels under a .github repository like the saltstack-formulas community did but each repository can have it's own labels even with conflicting names.

As an example for openssh-formula:

• issue [BUG] ssh_config multiple IdentityFile not supported saltstack-formulas/openssh-formula#176 use label bug defined in organisation .github repository
• issue sshd_config: wrong comment saltstack-formulas/openssh-formula#120 use label bug defined for this repository

Can forge take this into account?

Regards.

[tarsius]

Can forge take this into account?

Well of course it will have to.

On the other hand this sounds like the Github developers didn't fully think this through and should fix this by including the inherited labels in the list of a repository's labels. Edit: i.e. it should be a list of labels that "can be used in this repository".

[tarsius]

Dealing with this is likely to have far reaching consequences and I likely won't find the time to do anything about it any time soon. For now I have added a variable to opt out of using labels.

git config --local forge.kludge-for-issue-294 true

[baby-gnu]

Thanks, I did an update of forge and add the git config and I'm not blocked anymore.

[tarsius]

I tried to intentionally put a repository in this state in magit/hub-test3#2, but couldn't.

Because I'll likely delete that repository eventually, here's a copy of what I have written there:

Details

1. Assign default level invalid.
2. Try to create a new label, also named invalid. This fails.
3. Delete the label invalid.
4. Observe that the deleted label invalid is automatically removed from this issue.
5. Add a new level named invalid.
6. Assign the new level invalid.
7. Inspect data from api.

(ghub--graphql-vacuum
 '(query
   (repository
    [(owner "magit")
     (name  "hub-test3")]
    (issue [(number 2)]
           (labels [(:edges t)
                    (:singular label id)]
                   id
                   name))
    (label [(name "invalid")]
           id
           name)
    (labels [(:edges t)
             (:singular label id)]
            id
            name)))
 nil 'ghub--graphql-pp-response)

(data
 (repository
  (issue
   (labels
    ((id . "LA_kwDOM0lZ-88AAAAB4B6Qbg")
     (name . "invalid"))))
  (label
   (id . "LA_kwDOM0lZ-88AAAAB4B6Qbg")
   (name . "invalid"))
  (labels
   ((id . "LA_kwDOM0lZ-88AAAABvpXESg")
    (name . "bug"))
   ((id . "LA_kwDOM0lZ-88AAAABvpXETg")
    (name . "documentation"))
   ((id . "LA_kwDOM0lZ-88AAAABvpXEUQ")
    (name . "duplicate"))
   ((id . "LA_kwDOM0lZ-88AAAABvpXEVA")
    (name . "enhancement"))
   ((id . "LA_kwDOM0lZ-88AAAABvpXEWA")
    (name . "good first issue"))
   ((id . "LA_kwDOM0lZ-88AAAABvpXEXA")
    (name . "help wanted"))
   ((id . "LA_kwDOM0lZ-88AAAABvpXEYg")
    (name . "question"))
   ((id . "LA_kwDOM0lZ-88AAAABvpXEZQ")
    (name . "wontfix"))
   ((id . "LA_kwDOM0lZ-88AAAAB4B6Qbg")
    (name . "invalid")))))

Note how the label named invalid is in all three places associated with the same id LA_kwDOM0lZ-88AAAAB4B6Qbg.

The observed behavior is what one would expect after reading https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels#about-default-labels.

But in #294 we used to observe different behavior for https://github.com/saltstack-formulas/openssh-formula/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug.

Then I tried to reproduce the issue for https://github.com/saltstack-formulas/openssh-formula, and it turned out that they fixed this issue! We now get valid ids for all labels.

On the other hand this sounds like the Github developers didn't fully think this through and should fix this by including the inherited labels in the list of a repository's labels. Edit: i.e. it should be a list of labels that "can be used in this repository".

Maybe that was indeed the problem back then, but now the "default labels" are not shared between repositories of the organization. What happens instead is that when a new repository is created, the default labels are copied. There is no relation between the same label of two repositories or the template they were copied from. Even when these labels are identical otherwise, they each have their own id.

The "default labels" are templates, they are not actually shared between repositories.

Shortly I'll stop using the forge.kludge-for-issue-294 git variable.