Skip to content

fix: sync-upstream workflow silently fails to open PRs, leaving fork behind - #1

Merged
SmailG merged 1 commit into
mainfrom
claude/fork-sync-workflow-lag-o108mo
Jul 18, 2026
Merged

fix: sync-upstream workflow silently fails to open PRs, leaving fork behind#1
SmailG merged 1 commit into
mainfrom
claude/fork-sync-workflow-lag-o108mo

Conversation

@SmailG

@SmailG SmailG commented Jul 18, 2026

Copy link
Copy Markdown
Owner

Summary

The Sync upstream workflow has reported green on every scheduled run, but main has been stuck on upstream commit e46364b (2026-06-17, cursor#135) while the real upstream is now 14 commits / a month ahead at 3fe2823 (2026-07-14, cursor#156). The workflow never surfaced this because every failure-prone step was wrapped in || true.

Root cause, confirmed from the job logs of run 29565251942:

could not add label: 'sync' not found
no pull requests found for branch "sync/pstack-parity-sweep-with-the-private-skill-tree-156-14-commits"
  1. The workflow's permissions: block granted contents: write and pull-requests: write, but not issues: write — which gh label create needs. That call has been failing on every run, invisibly, because it was piped through 2>/dev/null || true.
  2. Since the sync label never actually got created (confirmed via the API — sync label does not exist in this repo), the subsequent gh pr create --label sync failed too — also swallowed by || true.
  3. Net result: the workflow correctly detects upstream changes, rebases, and force-pushes a sync/* branch every day (see e.g. sync/pstack-parity-sweep-with-the-private-skill-tree-156-14-commits currently in the branch list), but no PR has ever been createdgh pr list --state all returns zero results for this repo. gh pr merge --auto then silently no-ops too. The job exits 0 throughout, so the run shows "success" while nothing actually syncs.

Changes

  • Add issues: write to workflow permissions, so label creation actually succeeds.
  • Switch gh label create to --force (idempotent update-or-create) instead of swallowing stderr — keeps the "already exists" case silent while letting genuine errors surface.
  • After gh pr create, verify a PR actually exists for the branch (gh pr view) and fail the job loudly if not, instead of continuing silently on failure.
  • Turn a failed gh pr merge --auto into a visible ::warning:: annotation instead of a silent no-op, in case auto-merge is also disabled at the repo level.

Follow-up for a repo admin

Please double check Settings → General → Pull Requests → "Allow auto-merge" is enabled on this repo. The workflow calls gh pr merge --auto --rebase, and if that setting is off, PRs will now be created correctly but will need to be merged manually (the new warning annotation will call this out in the run logs if it happens).

Test plan

  • .github/workflows/sync-upstream.yml YAML parses successfully.
  • Once merged, confirm the next scheduled/dispatched run actually opens a PR for the outstanding 14-commit sync and that the sync label is created.
  • Confirm the PR either auto-merges or, if auto-merge is disabled repo-wide, that the new warning annotation appears in the run log.

The workflow's permissions block was missing issues: write, so
`gh label create sync` failed every run (silently, via 2>/dev/null ||
true). That left the `sync` label missing, which made the follow-up
`gh pr create --label sync` fail too (also swallowed by `|| true`).
Net effect: the job reported success every day while never actually
opening a sync PR, so main stayed pinned to upstream commit e46364b
(2026-06-17) even as upstream moved 14 commits ahead.

- Grant issues: write so label creation actually succeeds.
- Use `gh label create --force` instead of swallowing stderr, so the
  step is idempotent without hiding real errors.
- After `gh pr create`, verify a PR actually exists for the branch and
  fail the job loudly if not, instead of silently continuing.
- Surface (rather than swallow) auto-merge failures as a warning, so
  a disabled "Allow auto-merge" repo setting is visible in the logs.
@coderabbitai

coderabbitai Bot commented Jul 18, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)
  • sync

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro Plus

Run ID: eb252eee-c85e-4ac6-9dfb-3dafe27656b6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Note

.coderabbit.yml has unrecognized properties

CodeRabbit is using all valid settings from your configuration. Unrecognized properties (listed below) have been ignored and may indicate typos or deprecated fields that can be removed.

⚠️ Parsing warnings (1)
Validation error: Unrecognized key: "version"
⚙️ Configuration instructions
  • Please see the configuration documentation for more information.
  • You can also validate your configuration using the online YAML validator.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@SmailG
SmailG marked this pull request as ready for review July 18, 2026 00:03
@SmailG
SmailG merged commit 81e867e into main Jul 18, 2026
1 check passed
@SmailG
SmailG deleted the claude/fork-sync-workflow-lag-o108mo branch July 18, 2026 00:03
github-actions Bot pushed a commit that referenced this pull request Jul 18, 2026
The follow-up workflow_dispatch run after #1 merged failed hard on
`gh label create`:

  HTTP 403: Resource not accessible by integration
  (https://api.github.com/repos/cursor/plugins/labels)

Note the URL: gh was targeting cursor/plugins, not this fork. This job
adds a remote literally named `upstream` pointing at cursor/plugins
(to fetch its history for the rebase), and gh's implicit repo
resolution prefers a remote named "upstream" over "origin" when no
--repo/GH_REPO is given — a classic gotcha for exactly this fork+
upstream-remote layout. So every unscoped `gh label create`/`gh pr
create`/`gh pr list`/`gh pr merge` call in this workflow has actually
been aimed at cursor/plugins the whole time, where this token has no
access whatsoever. That's the real reason label/PR creation always
failed — the previous fix (#1) just stopped hiding it.

Set GH_REPO: ${{ github.repository }} at the job level so every `gh`
call is unambiguously pinned to this fork regardless of which git
remotes exist.
github-actions Bot pushed a commit that referenced this pull request Jul 18, 2026
The follow-up workflow_dispatch run after #1 merged failed hard on
`gh label create`:

  HTTP 403: Resource not accessible by integration
  (https://api.github.com/repos/cursor/plugins/labels)

Note the URL: gh was targeting cursor/plugins, not this fork. This job
adds a remote literally named `upstream` pointing at cursor/plugins
(to fetch its history for the rebase), and gh's implicit repo
resolution prefers a remote named "upstream" over "origin" when no
--repo/GH_REPO is given — a classic gotcha for exactly this fork+
upstream-remote layout. So every unscoped `gh label create`/`gh pr
create`/`gh pr list`/`gh pr merge` call in this workflow has actually
been aimed at cursor/plugins the whole time, where this token has no
access whatsoever. That's the real reason label/PR creation always
failed — the previous fix (#1) just stopped hiding it.

Set GH_REPO: ${{ github.repository }} at the job level so every `gh`
call is unambiguously pinned to this fork regardless of which git
remotes exist.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants