Pull request failures

Before creating a pull request

Use this page when connected remediation cannot create a pull request, patch branch or repository-backed change. The fix task owns the generated patch, customer approval, repository connection, branch state, PR link and ticket-only fallback.

• Open the fix task
• Check `approval_status`, `repository_id`, `branch_name`, `patch_status` and `pull_request_url`.
• Keep patches review-only until the customer approves connected remediation.

Triage the fix task

Follow the path `Report → Fix task → Patch approval → Repository branch → Pull request, ticket fallback or stop`.

1. Open `/fix-tasks/{fixTask}` from the report remediation panel. Result: `fix_task_id`, `approval_status`, `repository_id`, `branch_name` and `pull_request_url` are visible before retry.
2. Read `patch_status`, `repository_permission_status`, `branch_conflict_status`, `base_branch`, `repository_provider` and `pull_request_status`. Result: WebRiskOps separates approval, repository, branch and provider policy blockers.
3. If `PATCH_APPROVAL_REQUIRED` appears, keep the patch review-only until the customer approves. Result: no branch or PR is created before approval.
4. If `REPOSITORY_PERMISSION_MISSING` or `REPOSITORY_AUTH_REVOKED` appears, open `/settings` and recover the repository connection. Result: repository access is fixed through the product connection flow.
5. If `PATCH_BRANCH_CONFLICT` or `REPOSITORY_BRANCH_PROTECTED` appears, choose a safe branch name or base branch. Result: protected branches are not overwritten.
6. If `PULL_REQUEST_CREATION_FAILED` appears, retry from `/fix-tasks/{fixTask}/pull-request` only after approval, repository access and branch state are clear. Result: PR creation remains attached to the fix task.
7. If repository write access is unavailable or customer policy forbids PRs, generate ticket-only fallback and check `ticket_fallback_status`. Result: the customer still gets safe remediation instructions without a write connection.
8. If a PR exists, open `pull_request_url` and verify provider status before retrying. Result: duplicate PRs are not created for the same fix task.
9. Revoke or rotate repository access when the target repository is wrong, stale or unsafe, then confirm `revoke_status`. Result: credentials stop working before a new target is saved.
10. Continue to Fix tasks, Connected access requirements, Ticket-only fallback or Provider connection errors based on the owner that remains. Result: the next guide owns patch, access, fallback or provider recovery.

Pull request failure reasons

Use the reason code to decide whether approval, repository access, branch naming or fallback owns the block.

• `PATCH_APPROVAL_REQUIRED` means the customer has not approved connected remediation for this fix task.
• `REPOSITORY_PERMISSION_MISSING` and `REPOSITORY_AUTH_REVOKED` mean repository access must be reconnected before branch or PR creation.
• `PATCH_BRANCH_CONFLICT` and `REPOSITORY_BRANCH_PROTECTED` mean the chosen branch or base branch cannot accept the generated patch safely.
• `PULL_REQUEST_CREATION_FAILED` means approval, repository and branch checks passed far enough to attempt PR creation, but the provider rejected or failed the request.
• `PULL_REQUEST_POLICY_BLOCKED` and `TICKET_ONLY_FALLBACK_REQUIRED` mean customer policy or repository access keeps the task out of connected write mode.

Retry ticket fallback or stop rules

Retry only after the owning blocker changes.

• Use `/fix-tasks/{fixTask}/pull-request` only after approval, repository access and branch state are ready.
• Keep repository tokens inside the product connection flow and revoke stale access through `/settings`.
• Use ticket-only fallback when write access is unavailable, branch protection blocks the patch or the customer policy forbids PRs.
• Stop when the repository is not customer-owned, the target branch is unsafe or the patch would touch files outside the approved remediation scope.

Ready and blocked pull request states

A pull request is ready when the patch, approval, repository and branch all match the customer-approved task.

• Ready: patch is generated, customer approval is recorded, repository connection is active, branch is safe, provider accepts PR creation and `pull_request_url` points to the generated PR.
• Still blocked: approval pending, repository permission missing, revoked auth, protected branch, branch conflict, policy block, unsupported repository mode or ticket fallback required.
• Stop: customer policy forbids repository write access, the repository target is wrong or the requested change is outside the approved remediation scope.

Continue after pull request triage

Use the linked guide for the workflow that still owns the block.

• Fix tasks explains generated patches, task state and remediation ownership.
• Connected access requirements explains repository connection, minimum scopes and revoke boundaries.
• Ticket-only fallback explains safe remediation when connected write access is unavailable.
• Automation boundaries explains why WebRiskOps cannot push unapproved or out-of-scope changes.
• Provider connection errors explains auth, base URL, permission and rate-limit provider recovery.