[joseph-sentry]

The GitHub provider put branch names and refs into URL paths without encoding them. # and % are legal in git ref names, so a branch like feature/#123-fix was created fine (the name goes in the request body), but every later call that names it in the path was cut off at the # and hit feature/ instead.

In Seer that means reading the wrong branch's head, and a forced update could overwrite a different branch (raised on getsentry/seer#9354).

The provider now percent-encodes branch names, refs and SHAs before they go into a path, keeping / literal as GitHub expects. That covers getting, updating and deleting a branch, get_git_ref, commits, compare, check runs and archive links. GitLab already encoded branch names.

Not covered here: file paths in the contents endpoints have the same issue.

Verification

Ran through Sentry's scm-rpc proxy (a box's devserver) against a test repo with the branch seer/test/#12-50%-encode-e2e:

== unfixed (sentry-scm 3.0.0)
FAIL get_branch: ResourceNotFound "Branch not found"
== fixed
OK   create_branch
OK   get_branch            ref=seer/test/#12-50%-encode-e2e
OK   get_git_ref           ref=refs/heads/seer/test/#12-50%-encode-e2e
OK   update_branch force
OK   delete_branch

The box runs Sentry as one process, so the control-silo integration proxy hop isn't exercised. That hop sends the path from the already-encoded request URL in a header and rebuilds the URL with urljoin, which keeps %23 and %25 as they are.

🤖 Generated with Claude Code