Skip to content

Split phabricator.submit_patch into submit_patch and update_patch#6382

Draft
suhaibmujahid wants to merge 1 commit into
mozilla:masterfrom
suhaibmujahid:worktree-split-phab-patch-actions
Draft

Split phabricator.submit_patch into submit_patch and update_patch#6382
suhaibmujahid wants to merge 1 commit into
mozilla:masterfrom
suhaibmujahid:worktree-split-phab-patch-actions

Conversation

@suhaibmujahid

Copy link
Copy Markdown
Member

Why

phabricator.submit_patch did double duty: create a revision, or update one if an optional revision_id was passed. That put the create-vs-update decision entirely on the agent getting one optional argument right. Omit it by mistake and a new revision appears instead of the intended update; pass a guessed number and an unrelated revision gets a new diff.

What changed

Two agent-facing tools, each with only the parameters its case needs:

Tool Required Optional
phabricator.submit_patch (create) bug_id, title, reasoning summary, ref
phabricator.update_patch (update) bug_id, revision_id, reasoning title, summary, ref
  • submit_patch no longer accepts a revision_id at all, so it cannot update anything. Its title is now required by the schema rather than by a runtime ToolError.
  • update_patch requires revision_id; title/summary are omitted to keep the revision's current values (the handler already fetched them, this just makes it the documented default).
  • Apply-side stays one handler, renamed PatchSubmissionHandler, registered for both action types: the Conduit calls are identical apart from the revision id.
  • Both places gated on "this run submits a patch" now check a shared PATCH_ACTION_TYPES set: the diff artifact built in publish_changes, and the WIP policy injected in hackbot-api.
  • Enabled both action types for the bug-fix agent and pointed its system prompt at the create tool by default.

Drive-by: both tool docstrings advertised {{actions.<ref>.url}}, but the applied result exposes revision_url. Corrected.

Testing

libs/hackbot-runtime (148 passed) and services/hackbot-api (49 passed) suites pass, plus ruff check/format. New coverage: the two tools' recorded params and schemas (revision_id absent from create, required for update), both types routing to the handler, and both types triggering the diff artifact and the WIP injection.

One tool that both created and updated a revision meant the agent had to get
an optional `revision_id` exactly right: omitting it silently created a new
revision, and passing a guessed one silently updated a stranger's.

Now `phabricator.submit_patch` creates (bug_id + required title + summary) and
`phabricator.update_patch` updates (bug_id + required revision_id, with title
and summary optional and defaulting to the revision's current values). Each
tool only accepts the parameters its own case needs, so the schema itself rules
out the wrong call.

Apply-side stays one handler (renamed PatchSubmissionHandler) registered for
both types, since the Conduit calls are identical apart from the revision id.
Places gated on "this run submits a patch" now check the shared
PATCH_ACTION_TYPES set: the diff artifact built in publish_changes and the WIP
policy injected in hackbot-api.

Also corrects the ref-placeholder example in both tool docstrings: the applied
result exposes revision_url, not url.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant