fix: use gh repo set-default for PR lookup on forks - #2004
Merged
Conversation
When origin points to a fork, `wt switch pr:N` would query the fork for the PR and get a 404. The error message suggested running `gh repo set-default`, but worktrunk never actually used that setting. Now `fetch_pr_info` checks `gh repo set-default --view` first and uses the configured repo for the API call. Falls back to the primary remote when no default is set. Closes #2002 Co-Authored-By: Claude <noreply@anthropic.com>
worktrunk-bot
commented
Apr 8, 2026
worktrunk-bot
left a comment
Collaborator
Author
There was a problem hiding this comment.
Clean fix — gh_default_repo fallback is well-designed and the error messages are context-aware. Two minor suggestions below.
split_once('/') already returns None for empty slugs. The guard
for empty owner/repo after split_once was unreachable and flagged
by codecov.
Co-Authored-By: Claude <noreply@anthropic.com>
Owner
|
@worktrunk-bot do you see the suggestions? |
- Add exit-code check (.filter(|o| o.status.success())) to gh_default_repo to prevent misparsing non-zero exit stdout - Use MockConfig builder in test instead of hand-written JSON for consistency with other mock tests Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Collaborator
Author
|
Yes — applied both suggestions in e24290c:
|
Co-Authored-By: Claude <noreply@anthropic.com>
Owner
|
ok, open an issue on the tend repo for why @worktrunk-bot didn't see the suggestions initially |
Collaborator
Author
|
Opened max-sixty/tend#177 — |
max-sixty
pushed a commit
that referenced
this pull request
Apr 8, 2026
## Problem The tend workflow files were generated from an older version of `tend` that includes bot-author filters on `pull_request_review` and `pull_request_review_comment` events. This prevents `tend-mention` from triggering when the bot reviews its own PR, so review suggestions sit unapplied until a human intervenes (as happened on #2004). The upstream fix (max-sixty/tend#168) was merged but hasn't been released to PyPI yet, so `uvx tend@latest init` still generates the old templates. ## Solution Regenerated workflow files from `tend@main` (commit `ffc84f49`) which includes the fix. Key changes: - **tend-mention.yaml**: Removes `!= 'worktrunk-bot'` filters from `pull_request_review` and `pull_request_review_comment` events. Self-conversation loop prevention is now handled at the prompt level instead. - **tend-triage.yaml**: Removes `if: github.event.issue.user.login != 'worktrunk-bot'` filter. - **All files**: Adds "do not edit" header comments. - **.github/CLAUDE.md**: Updated to reflect the new loop prevention model. ## Testing These are generated workflow files — no code tests needed. The changes match the upstream template exactly (`uvx --from 'git+https://github.com/max-sixty/tend.git@main#subdirectory=generator' tend init`). --- Closes #2008 — automated triage Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When
originpoints to a fork,wt switch pr:Nqueries the fork's repo for the PR and gets a 404. The error message suggests runninggh repo set-default, but worktrunk never actually read that setting — the hint was misleading.Reported in #2002 with a diagnostic log showing the issue clearly:
gh api repos/JustinPierce/the-repo/pulls/2899returns 404 because the PR is on the upstream repo.Solution
fetch_pr_infonow checksgh repo set-default --viewfirst. If a default repo is configured, it uses that for the API call. Falls back to the primary remote URL when no default is set (preserving existing behavior).The 404 error message is also context-aware: when using the gh default, it suggests checking the configured repo rather than re-running
gh repo set-default.Testing
test_switch_pr_fork_gh_default_repo: origin = fork, upstream = parent,gh repo set-default --viewreturns parent repo → PR lookup succeedsCloses #2002 — automated triage