[Bug]: Shared project filter in Tasks generates errors #15784

Activity

1. jhovanyamaya

   added

   bugSomething isn't workingSomething isn't working

   on Aug 21, 2026
2. jhovanyamaya

   added the

   Bug

   issue type on Aug 21, 2026
3. github-actions

   added

   os:linuxIssues affecting LinuxIssues affecting Linux

   on Aug 21, 2026
4. OrcaWin

   added

   git

   on Sep 19, 2026
5. aprudkin commented on Oct 21, 2026

   

   aprudkin

   on Oct 21, 2026

   More actions

   Confirmed still reproducible in Orca 1.4.232 on macOS 27.0 (Apple Silicon / arm64).

   Reproduction and actual result

   1. Have a mixture of GitHub and self-hosted GitLab repositories registered in Orca.
   2. Open Tasks → GitHub → Issues, with All projects selected.
   3. GitLab-only projects appear as persistent status rows:

   No GitHub source detected for <gitlab-project> — it may have no GitHub remote, or the source could not be resolved.

   Each row has a Retry button. In this installation, the header shows GitHub · Local Mac · 11 projects, and all five GitLab-only repositories produce these rows alongside the GitHub issue results. The same five rows were confirmed in two consecutive automated accessibility snapshots.

   Verification

   • Read-only git config --get-regexp '^remote\..*\.url$' checks confirm that each affected repository has exactly one remote, pointing to the self-hosted GitLab server, and no GitHub remote.
   • orca repo list --json already records the correct GitLab gitRemoteIdentity for all five affected repositories. This is not an incorrect remote in Orca's stored repository metadata.
   • No remotes, authentication settings, or application files were changed during diagnosis.

   Implementation evidence from the installed 1.4.232 renderer bundle

   The selection model builds a common eligible repository list and derives selectedRepos from the selected IDs, without filtering that selection by the active task provider. The shared eligibility predicate admits Git repositories with a known Git remote identity; it is not limited to GitHub identities.

   The GitHub unresolved-source selector then adds a selected repository when:

   state?.sources && !state.sources.issues && !state.sources.prs && !state.error

   Those entries are rendered as the missing-GitHub-source rows above, with Retry. Thus a valid GitLab-only repository is treated as an unresolved GitHub source rather than as a repository that is not applicable to this provider.

   This was traced in the installed TaskPage-BBgc1Vsw.js and its shared task-selection helper bundle, not verified against the current development branch.

   Expected behavior / regression coverage

   With mixed GitHub/GitLab projects and All projects selected, the GitHub task view should not emit missing-source/Retry rows for repositories already known to be GitLab-only. Distinguish a known non-applicable provider from an actual failure to resolve an applicable source. Provider-specific selection and/or filtering should preserve legitimate source-resolution errors and GitHub Enterprise support.

   A regression test should cover mixed-provider selection and assert that a known GitLab-only repository does not produce a GitHub unresolved-source row, while a genuine GitHub source-resolution failure remains visible.

   Private repository names, paths, and the self-hosted GitLab address have intentionally been omitted. The reverse-direction GitLab-view behavior described in the original report was not retested in this reproduction.
6. yasu00000 commented on Oct 21, 2026

   

   yasu00000

   on Oct 21, 2026

   Contributor

   More actions

   Thanks for the detailed reproduction — this is what #30151 fixes. Each repo-backed source now narrows the shared selection before it queries anything: a repo whose origin is already known to be on the other forge is never resolved, never counted as failed, and is listed in one collapsed "Skipped — hosted on GitLab (n)" row without Retry. Repos Orca cannot place (no remote, or a host neither CLI knows) keep today's resolve-and-Retry path, so a genuine source-resolution failure still shows, and GitHub Enterprise origins stay on the GitHub side. A self-hosted GitLab origin is recognized through the hosts glab auth status reports as logged in. The matcher and scope tests cover mixed GitHub / gitlab.com / self-hosted selections and GitHub Enterprise hosts.
7. aprudkin commented on Oct 23, 2026

   

   aprudkin

   on Oct 23, 2026

   More actions

   Follow-up from new user-provided screenshots on 2026-10-23: both directions of this issue are still visible in the current installation. The installed macOS app reports version 1.4.232 in its bundle metadata; this is not a claim about a newer release or the current development branch.

   • Tasks → GitHub → Issues → All projects, query is:issue is:open: the header shows 12 projects, and the table contains six separate “No GitHub source detected for — it may have no GitHub remote, or the source could not be resolved.” rows, each with Retry. These repeated source-status rows occupy the issue table instead of being distinguished from task results or grouped into a compact status section.
   • A separate screenshot of Tasks → GitLab → MRs → All projects shows None of the git remotes configured for this repository point to a known GitLab host and Configured remotes: github.com. This adds screenshot evidence for the reverse direction, which my earlier comment explicitly did not retest.

   For repositories known to belong to the other forge, please avoid presenting normal provider non-applicability as a retryable per-project error. Preserve genuine source-resolution/access failures and keep them distinguishable from an empty task list. A compact grouped/skipped state, such as the one proposed in #30151, would address the repeated-row presentation without hiding real failures.

   Evidence boundary: this follow-up records the supplied screenshots and installed-version metadata, not a new independent automated reproduction, source-level diagnosis, or verification of #30151. The previous read-only reproduction in this thread remains separate evidence. No application files, remotes, credentials, or project settings were changed for this follow-up. Private project names/paths and the full screenshots have intentionally not been uploaded.
8. yasu00000 commented on Oct 23, 2026

   

   yasu00000

   on Oct 23, 2026

   Contributor

   More actions

   Thanks for the reverse-direction screenshot as well. #30151 handles both views the same way: the GitLab tab collapses repos whose origin is github.com (or a GitHub Enterprise host) into a single "Skipped — hosted on GitHub (n)" row without Retry, mirroring the GitLab row on the GitHub tab. Repos Orca cannot place on either forge keep the real resolve error.