Why a PR wasn't drafted
Every reason Watari stops short of opening a draft pull request, what each one means, and the fastest way to unblock it.
Why a PR wasn't drafted
Watari would rather open no pull request than open a bad one. When it stops, the bug detail page shows a short reason and links to the matching section below.
Every reason on this page is recoverable. None of them cost you a Mapped Bug — the meter fires when a bug maps to code, before any PR work starts, so a withheld PR never changes your bill.
Most of these are fixed by adding information and clicking Retry on the bug detail page. If a retry produces the same reason twice, the fix is upstream — in the ticket, the repository settings, or the code itself.
Code mapping confidence too low
What it means. Watari found candidate files for this bug, but none of them cleared the confidence bar required to edit code automatically.
Why Watari stopped. A low-confidence location is a guess. Editing a file Watari isn't sure about produces a diff your engineers have to reverse-engineer before they can reject it, which is slower than writing the fix by hand.
What to do. Open the bug and add engineering context — a file path, a function name, an endpoint, or a one-line description of where you think the code lives. Then click Retry. If mapping keeps failing for a whole category of bug, the affected code may live in a repository you haven't connected.
Bug lives in vendored or closed-source code
What it means. The failure appears to originate in a dependency rather than in code you own — a vendored package, a compiled artifact, or a third-party library.
Why Watari stopped. Watari only edits source you control. Patching a dependency in place would be overwritten by the next install, and Watari has no visibility into a closed-source vendor's internals.
What to do. Route the issue to the upstream vendor, or, if you maintain a fork, pull the dependency in-tree so it is part of an indexed repository and retry. If the real fix is a workaround in your own code, add that direction as engineering context and retry.
Insufficient context to draft a safe fix
What it means. Watari understood that something is broken but couldn't determine what the correct behaviour should be.
Why Watari stopped. A fix needs a target, not just a symptom. "The export is wrong" doesn't say whether the number, the format, or the filter is wrong — and guessing produces a confident-looking PR that fixes nothing.
What to do. Add what the customer expected to happen alongside what actually happened. Reproduction steps, a screenshot, the exact input that triggers it, or a link to a related issue all work. Then retry.
Bug pattern is too broad to fix in one PR
What it means. The change would touch a cross-cutting concern — logging, authentication, error handling, validation — across many files at once.
Why Watari stopped. A sweeping mechanical change across a codebase is exactly the kind of diff that is hardest to review and easiest to get subtly wrong. Watari is deliberately conservative here.
What to do. Narrow the scope. Pick the one call site or one module the customer actually hit, note it as engineering context, and retry — Watari will draft the targeted fix. Roll the broader cleanup into your own refactor.
Language or framework not supported
What it means. The file that needs to change is in a language Watari doesn't yet generate fixes for.
Why Watari stopped. Watari writes fixes only in languages it can parse and validate. Without that, it can't check its own work before pushing.
What to do. The mapping still stands — the bug detail page shows you the file and function, which is the slow part. Write the fix by hand from there. If this blocks a language your team depends on, tell us; supported-language coverage is driven by what customers ask for.
AI processing paused for this organization
What it means. Your workspace hit its monthly processing limit, a fair-use safeguard applied per organization.
Why Watari stopped. The cap exists so a runaway loop or an unexpected ticket spike can't quietly consume your whole allowance.
What to do. Request a limit increase from the PR tab on the bug detail page. Most requests are approved immediately based on your usage history. Mapping and billing are unaffected — only fix generation is paused.
PR target branch is missing
What it means. The branch Watari was configured to open pull requests against doesn't exist on the repository.
Why Watari stopped. There is nothing to branch from or merge into. This is almost always a branch that was renamed or deleted after the repository was connected.
What to do. Open Settings → Integrations, pick an existing branch for that repository (or create the branch in your Git host), then retry. Repositories connected after a master → main rename are the common case.
Watari declined to draft this fix
What it means. A safety check that doesn't fit the categories above stopped the draft.
Why Watari stopped. The specific reason is recorded on the bug. This bucket exists so a rare cause is still explained rather than silently dropped.
What to do. Read the reason shown on the bug detail page — it names the specific concern. If it's addressable, address it and retry; if not, the mapped code locations are still there to fix by hand.
Credential detected in generated code
What it means. The proposed change would have written an apparent credential — an access key, a token, a private key — into a file in your repository. Watari withheld the entire pull request. Nothing was pushed and no branch was created.
Why Watari stopped. Committing a live credential is not a code-quality problem you can fix in review; it is a disclosure that happens the moment the push lands, and it survives in Git history after the commit is reverted. Withholding the PR is the only action that keeps the credential out of your repository.
Watari distinguishes two cases, and only one of them stops the PR:
- A credential the change would add. The literal appears in the proposed version of the file and not in the version already in your repository. This is a new disclosure, and it blocks the pull request.
- A credential already committed in your repository. The literal is already in the file Watari is editing, and the proposed version simply carries it forward. Watari does not stop for this — the disclosure already happened, and refusing to touch the file wouldn't undo it. (It's still worth rotating.)
The credential almost always arrives from one of three places: pasted into the support ticket by a customer or agent, included in a review comment Watari was asked to act on, or already sitting in the file being edited.
What to do.
- Rotate the credential. Assume it is compromised. It has been sitting in a support ticket, a comment, or a source file, and you should not assume the copy Watari saw was the only one.
- Remove it at the source. Redact it from the ticket or the review comment, or replace the hard-coded value in the file with a reference to your secrets manager or an environment variable.
- Re-run. Click Retry on the bug detail page.
There is no override. Watari will not push a credential into your repository on request, and it does not keep a copy of the withheld change waiting to be released — holding one would mean storing your source code and a live credential together, which is exactly what we commit to never doing. The retry is the release valve, and it is free: a withheld PR does not count against this bug's retry limit.
Next: Code to PR — how the draft pull request is built, verified, and iterated — the full path from confirmed code locations to a reviewed pull request.