Repository navigation
Conversation
…e branch The verify-attach workflow published only when the commit a session started on was a commit of the pull request. A session that comes up on the commit the branch came from, so that it can make the before run, started on a commit of the base branch. Its evidence was refused, and the only way out was a second session on the pushed change. The workflow now also takes a start commit that the base branch of the pull request holds. It asks GitHub to compare that commit with the base of the pull request, and takes only `ahead` or `identical` as a yes. The commit of the run must still be a commit of the pull request, and every other check is unchanged. `attach` checks the same rule before it hands off. The workflow file and the session agent of such a session come from the base branch, so the change trusts no code that the old rule did not. A session that started on a commit of neither the pull request nor its base branch is still refused. One session now does the before run and the run of the change, so the skill gives one order of work and says to open the pull request after the last run. The script, the two files under src/core/remote/ and the test files are the bytes of clerk-ios. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: e2d4892 The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: true
Comment |
mikepitre
added this pull request to stack #10100
October 14, 2026 00:21
GitHub answers 404 to the comparison of a start commit that the repository no longer has. The publish job failed on that answer, and `attach` said to retry, which cannot change it. The job now prints a notice that names the reason and publishes nothing. `attach` fails with the reason and says to start a session on a commit of the pull request or of its base branch. Any other failed comparison still fails the job, and `attach` still says to retry. `publish --dry-run` with `--compare` and no file after it asked GitHub instead of reading a file. It now prints the usage and exits with 2. The order of work in the skill names `--before <run-id>` at the `attach` step again. What differs between a local device and a remote session has a paragraph of its own. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@clerk/astro
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/electron
@clerk/electron-passkeys
@clerk/eslint-plugin
@clerk/expo
@clerk/expo-biometrics
@clerk/expo-google-signin
@clerk/expo-native-components
@clerk/expo-passkeys
@clerk/express
@clerk/fastify
@clerk/hono
@clerk/localizations
@clerk/mosaic
@clerk/nextjs
@clerk/nuxt
@clerk/react
@clerk/react-router
@clerk/shared
@clerk/tanstack-react-start
@clerk/testing
@clerk/ui
@clerk/upgrade
@clerk/vue
commit: |
This branch was successfully deployed
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.
Description
This is the same change as clerk/clerk-ios#691, for the Expo package in
integration/expo-native/. clerk/clerk-android#1089 is the same change for clerk-android. This PR sits on #10219.A cloud agent ran the verify skill from start to finish on clerk/clerk-ios#690, a trial that is closed now. It pushed its branch at
main, started a borrowed-device session, made the before run, pushed the change, opened the pull request, and made the after run in the same session. Thenattachrefused to hand the evidence off. The publish workflow took a session only when the commit it started on was a commit of the pull request, and this session had started on the commit the branch came from, which is a commit ofmain. The agent had to end the session and start a second one on the pushed change. That cost 13 more minutes, and the pull request was open without its evidence for 20 minutes.After this PR:
scripts/verify-attach.mjstakes a session when the commit it started on is a commit of the pull request, or a commit that the base branch of the pull request holds. For the second case it asks GitHub to compare the start commit withbase.shaof the pull request, and it takes onlyaheadoridenticalas a yes. Any other answer, an answer that is not JSON, and a base that is not a commit id all count as a no. When GitHub does not find the start commit in the repository, the job prints a notice that says so and publishes nothing. Whenghcannot make the comparison for another reason, the job fails. The commit of the run must still be a commit of the pull request, and no other check changes.attachchecks the same rule before it hands off, inpullRequestMismatchinintegration/expo-native/src/core/remote/handoff.ts. The workflow checks the script out alone, so the two cannot share code. Each side states the rule once, and their tests cover the same cases. When GitHub does not find the start commit,attachfails with that reason and says to start a session on a commit of the pull request or of its base branch.SKILL.mdgives one order of work for a local device and a remote session: branch, push,up, before run, change, commit, push, after run, open the pull request,attach,down. The two-session recipe is gone, and so is the sentence that said to open the pull request beforeup. The pull request is opened after the last run so that it is not left open without its evidence. On a remote session the evidence reaches the description about a minute afterdown.publish --dry-runcan read the comparison from a file with--compare <file>, next to--pulland--commits. The workflow passes none of them.--comparewith no file after it prints the usage and exits with 2.The script,
backend.ts,handoff.tsandtest/handoff.test.tsare byte copies of the files of clerk/clerk-ios#691.scripts/verify-attach.test.mjsdiffers from the file there in one line, which importsdescribeanditfromvitest. The changeset is empty, as it is in the other PRs of the stack. No published package changes.Why the new rule is safe. The publish job runs no code from a session. It reads the artifact, checks it against its own limits, and writes what the session reported under the name of the account that started it. The start commit decides only which
verify-remote.ymland which session agent ran on the runner. A session that started on a commit of the base branch ran the ones the base branch already has. A session that started on a commit of the pull request ran whatever that commit holds, and the old rule took those. So the new case trusts no code that the old rule did not. The start commit comes from the run that GitHub records, the base from the pull request that GitHub returns, and the answer from GitHub, so nothing more is taken from the session.Apart from this case, the old rule refused a session whose start commit the history of the pull request no longer has, such as one that started before the branch was rewritten. That session is still refused, because its commit is on neither side. In a stack like this one, the base branch of a pull request is the branch below it, so a session may start on a commit of that branch.
npm testinintegration/expo-native/passes 793 of 793, where #10219 has 787, andnpm run typecheckis clean.vitest run --root scripts verify-attachpasses 196 of 196, where #10219 has 190. At the first commit of the rule, each of 38 deliberate breaks of the new condition failed at least one test. 20 were in the script and 18 in the CLI. Each of 12 breaks of the fix that followed it, six on each side, fails a test at this head. clerk/clerk-ios#691 has the run of both scripts on the real values of clerk/clerk-ios#690. The script onmainthere refuses that session, and this one accepts it in a dry run.Not proven:
verify-evidenceenvironment. This repository is public and GitHub answers such a comparison to a request with no token, so that token should read it too. It has not run with that token.main, and this stack is not onmainyet.base.shais always a commit of the base branch is read from four merged pull requests of clerk-ios, not from GitHub's documentation.Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change
🤖 Generated with Claude Code