Why a fix wasn't drafted
Every reason Watari stops short of a draft fix, what each one means, and the fastest way to unblock it.
Watari would rather write no draft fix than a bad one. When it stops, the issue 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 Watari finds a bug in your code, before any drafting starts, so a held-back draft fix never changes your bill.
Most of these are fixed by adding information and clicking Retry on the issue page. If a retry produces the same reason twice, the fix is upstream: in the ticket, the repository settings, or the code itself.
No strong match in your code
What it means. Watari found candidate files for this bug, but none of them was a strong enough match to edit code automatically.
Why Watari stopped. A weak match 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. Your detail is the go-ahead: Watari tries the fix in the repository that holds the file you name (or its strongest match if you name none), even though the match alone was too weak, and still opens a draft only if it is confident in the fix. If Watari keeps missing the code for a whole category of bug, the affected code may live in a repository you haven't connected.
The problem is in code Watari cannot see
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 a connected repository and retry. If the real fix is a workaround in your own code, add that direction as engineering context and retry.
Not enough detail to write 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 convincing-looking draft fix 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.
The change is too wide for one draft fix
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 code Watari found still stands: the issue 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 code locations Watari found 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 Fix section of the issue page. Most requests are approved immediately based on your usage history. Finding the code and billing are unaffected, only drafting fixes is paused.
The branch for draft fixes 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 → Connected tools, 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 issue page. It names the specific concern. If it's addressable, address it and retry; if not, the code locations Watari found are still there to fix by hand.
Draft fix held back: a credential was found in the change
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 held back the whole draft fix. 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. Holding back the draft fix is the only action that keeps the credential out of your repository.
Watari distinguishes two cases, and only one of them stops the draft fix:
- 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 draft fix.
- 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 issue 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 always open: once the credential is removed at its source, press Try again.
Nothing to change in the code
What it means. Watari read the code and found it already does what the report asks, or your team told Watari there is nothing to change (for example the report came from an old cached copy of a page). Nobody needs to write a fix.
Why Watari stopped. There is no defect to fix. A draft that changed working code would only add risk.
What to do. The issue reads Your move · Close it.
- Close it. Mark the issue Won't fix on the issue page, or close it in your tracker. Watari's comment on the tracker item says the same.
- Tell the customer. The issue page suggests a reply: the behaviour they reported works on the current version, and they can try again on the latest page.
- If it still happens, tell Watari where to look, on the issue page or as a reply on the tracker item mentioning Watari, and it tries again with what you said.
The cause looks to be in database code Watari cannot read
What it means. The code Watari found calls a stored procedure or database function, and the problem looks to be inside it: the rows it returns, a filter, a calculation or a status it sets. The definition of that procedure is not in any repository you connected.
Why Watari stopped. Watari only changes code it can read. Changing the code that calls the procedure to work around a defect inside it hides the defect from whoever owns the database and can break every other place that calls it. How Watari decided on the issue names the procedure.
What to do.
- If your database code is in a repository (a database project, migration scripts or one file per procedure), connect that repository in Codebase. Once Watari has read it, retry the draft fix from the issue page.
- If it lives only in the database, a developer fixes this one in the database. Keeping procedures in a repository lets Watari draft the next one.
- If you know the problem is in the calling code after all, tell Watari where to look, on the issue page or as a reply on the tracker item mentioning Watari, and it tries again.
The file is too large for a draft fix
What it means. Every file Watari found for this bug is larger than 1MB, so Watari did not attempt a fix.
Why Watari stopped. Above roughly a megabyte, an automated change can no longer be checked reliably. A partial edit could silently remove working code, so Watari refuses before doing any work.
This is a limit on fixing, not on understanding. Getting your code ready and finding the code handle large files normally, so the bug report, the match strength and the file and line locations on the bug are all accurate. Only the draft fix is held back.
What to do.
- Fix it by hand. The code 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 change automatically. 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 an automated change stops being safe, so raising it would trade a missing draft fix for a corrupted one.
Next: Code to fix: how the draft fix is built and checked, the full path from the code Watari found to a reviewed pull request.