fix(agent-builder): resolve target revision for set_secret/connect_mcp punch-outs#3323
Open
dmarticus wants to merge 3 commits into
Open
fix(agent-builder): resolve target revision for set_secret/connect_mcp punch-outs#3323dmarticus wants to merge 3 commits into
dmarticus wants to merge 3 commits into
Conversation
…p punch-outs Since secrets moved to per-revision scope, the set_secret/connect_mcp client tools required a revision_id the agent never sends (the tool schemas don't define it) and fell back to an agent-config page context whose `revision` field was never populated — so every punch-out failed with `missing_arg: revision_id`. Resolve the target revision instead: explicit arg → the revision open on this agent's config page (now actually threaded from the configuration pane) → API fallback (newest draft for new secrets and MCP connections, live for rotations). Also expose the viewed revision in the get_context payload so the agent can target one explicitly. Generated-By: PostHog Code Task-Id: 2a145449-d5be-47f3-bee6-cf91a7baae89
|
Merging to
After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here |
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
Contributor
|
…targeting Review feedback: with mode "rotate", the page-context fallback could return the draft the user is viewing, writing the rotated secret to the draft while the running (live) revision kept the old value. Only honor the viewed revision for draft-preference resolution (new secrets, MCP connections); rotations always resolve live via the API. Generated-By: PostHog Code Task-Id: 2a145449-d5be-47f3-bee6-cf91a7baae89
… agent An explicit revision_id arg is now checked against the target agent (via the nested revision route, which 404s on mismatch) before the punch-out form is parked. The backend rejects mismatched writes anyway, but that failure would only surface at submit, after the user has already typed the secret into a doomed form. Generated-By: PostHog Code Task-Id: d37eba08-19ac-40f5-8035-e68f91f39ebc
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Every
set_secret(andconnect_mcp) punch-out in the agent builder fails withmissing_arg: revision_id. Since secrets moved to per-revision scope (#2749), the client tool handler requires a target revision — but the agent-builder's tool schemas don't definerevision_id, so the meta-agent never sends one, and the intended fallback (the revision open on the agent-config page) was dead code: nothing ever populatedrevisionin that page context. The result is that agents built in the builder can't get credentials set at all.Changes
useAgentBuilderClientTools: whenrevision_idisn't in the args, resolve it — the revision the user is viewing on this agent's config page, else via the API. New secrets and MCP connections target the newest draft (secrets only copy forward at draft creation, and spec PATCHes only land on drafts); rotations target the live revision.AgentConfigurationPaneinto the agent-builder page context (previously never set), and only trust it when it belongs to the agent the tool call targets.revision_idin theget_contextpayload so the agent can target a revision explicitly.How did you test this?
useAgentBuilderClientTools.test.ts(9 tests) covering explicit-arg, page-context, slug-mismatch, draft-vs-live preference by mode, newest fallback, no-revision and API-failure error paths, andconnect_mcpdraft targeting — all pass.pnpm --filter @posthog/ui typecheckandbiome checkclean.Automatic notifications
Created with PostHog Code