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.
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 Issue: 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.
The change belongs in a file that is not code
What it means. The wording or data that needs to change does not live in source code. It sits inside a file your repository ships as an asset: a spreadsheet, a document, an image, or a downloadable template.
Why Watari stopped. Watari edits source files and verifies the result still parses and builds. A binary asset offers neither: rewriting one blind could corrupt a file your product hands to customers, and Watari cannot read back what it wrote to check.
The common case is a downloadable template. A page offers a spreadsheet for customers to fill in, the wording customers complain about is a cell inside that spreadsheet, and the code only points at the file.
What to do. Update the asset in your repository and commit it, the mapped code locations tell you which file is being served and from where. If the value is in fact generated in code (a header written at export time, a label rendered into a document), say so as engineering context naming the file or function, and retry, Watari will draft that change.
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.
Target file is too large for an automated fix
What it means. Every file this bug maps to is larger than 1MB, so Watari did not attempt a fix.
Why Watari stopped. Watari drafts a change by rewriting the whole file and committing the result, which is what lets it verify the file still parses and still builds before opening the pull request. Above roughly a megabyte that rewrite stops being reliable: the model runs out of room mid-file, and a half-written file is far worse than no pull request, because it silently deletes working code. Refusing is the safe answer, and Watari refuses before spending anything rather than trying and hoping.
This is a limit on fixing, not on understanding. Indexing, mapping and everything upstream handle large files normally, so the bug report, the confidence score and the file and line locations on the bug are all accurate. Only the draft PR is withheld.
What to do.
- Fix it by hand. The mapped locations point at the right place, so the diagnosis work is already done.
- Consider splitting the file. A file over a megabyte is usually several responsibilities sharing a name, and it is hard for people to review for the same reason it is hard to rewrite. Once the relevant part lives in a smaller file, Watari drafts fixes for it automatically, with no configuration change.
There is no setting to raise the limit. It is not a quota we are rationing, it is the size above which the rewrite stops being safe, so raising it would trade a missing pull request for a corrupted one.
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.