Repository navigation
Describe vault fill as safe to retry - #687
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit a62cf9b. Configure here.
| `fill` doesn't click buttons or submit forms, but input/change handlers can trigger site behavior. `completed` doesn't mean login succeeded, a form was submitted, or payment succeeded. | ||
|
|
||
| **don't automatically retry `fill` after a failure or uncertain outcome.** a lost response can follow successful writes; another request can repeat events, overwrite edits, or generate a different totp code. deliberate recovery starts with inspecting the existing attempt, not replaying it. preserve per-field `index`, `status`, and any `error_code` for reconciliation. | ||
| **`fill` is safe to retry after a failure, an `unknown` outcome, or a lost response.** it never submits the form, so a retry only rewrites the same fields, and a `totp` field gets a fresh code. a retry right after an `unknown` result can wait up to 15 seconds for the earlier attempt's browser lock to expire. when a field `failed`, fix its cause, such as a selector that matched nothing, before retrying. |
There was a problem hiding this comment.
Dense fill-retry caveats packed together
Low Severity
The new retry guidance stacks several distinct caveats into one dense paragraph: retry is safe, a retry only rewrites fields, totp gets a fresh code, an unknown retry can wait 15s for the browser lock, and a failed field needs its cause fixed first. The Link outcome paragraph similarly packs completed-versus-paid, leftover writes, retry-versus-aliases, and never-retry-checkout into running prose. A short lead-in plus bullets would keep those points from being skipped.
Additional Locations (1)
Triggered by learned rule: Use bullet lists when covering multiple distinct points in guides
Reviewed by Cursor Bugbot for commit a62cf9b. Configure here.
This branch was successfully deployed
2 participants
Summary
fillwrites field values into a browser page and never submits the form or consumes the vault item, but the docs repeatedly told readers and agent prompts never to retry it (and to disable SDK retries for it). Agents following that guidance stall after a transient failure instead of re-running the fill.vaults/fill.mdx: drop themaxRetries: 0instruction, rewrite the outcome table and the no-retry callout to say fill is safe to retry, and note the up-to-15s browser-lock wait right after anunknownresultNo-retry guidance for
1pw_fill(which submits the form),webmcp_invoke,authorize, and checkout submission is unchanged. The API reference picks up the matching spec change from kernel/kernel#4692.