Merging a PR on a fork closes issue on upstream

I ran into the following case: there is a fork of scylladb/seastar called redpanda-data/seastar. Since it is a “github fork” (i.e., the fork was done through github so the forked repository is associated with the upstream in github) no issues can be created on the fork, only on the upstream.

I created an issue in the upstream, and later made a commit in the fork referring to that issue with a fixes #1035 annotation. This unexpectedly closed the issue on upstream. Is that by design? It seems strange that checking into a fork could mark issues fixed upstream, where no change as been made at all.

IMO it would make more sense if the issue was closed after the commit made it back upstream.

Do you have write access to scylladb/seastar?

By design, two repositories in an organization can conspire to behave as you’re experiencing (maybe one repository holds all the issues for 3 repositories, and the fixes are distributed amongst them). – An example of this is argocd (which has a couple of dependents) or rancher-desktop

It’s also possible to have a component in another organization (limavm comes to mind). This is the example you’re running into.

If you have write permissions, then it wouldn’t shock me if that explains what’s happening, but, I’d agree that it isn’t necessarily expected/ideal.

Fwiw, these days, you should probably submit your feedback here:
https://github.com/github/feedback/discussions/categories/pull-requests-feedback

Thanks Josh, for your answer.

I do not have write permissions to scylladb/seastar (as least as far as I can tell: the various UI elements that would let me modify the repo are not present, though maybe there is a better way to check for this).

So does this shock you now :)?

I was, of course, the owner of the original issue I submitted, so maybe this has something to do with it?

Travis

Hmmm, if you’re the owner of the thing that it closed, that might be relevant.