fix: resolve the gateway target for A/B test invocation URLs (#1854)

[jariy17]

Problem

Closes #1854.

agentcore run ab-test in config-bundle mode printed an invocation URL built from the runtime name, but a gateway invocation path segment must be a gateway target name. Whenever the two differed, every request to the printed URL failed:

{"success":false,"error":"No Target found for Target name: CustomerSupportAB"}

The same wrong URL was stored in .invocationUrl for agentcore view ab-test <id> --json, so scripts inherited it too.

The cause is one line in getInvocationUrl:

return record.agent ? `${baseUrl}/${record.agent}/invocations` : undefined;

record.agent comes from opts.runtime ?? opts.name (handler.ts), i.e. the runtime. It only happened to work when a gateway target was named identically to its runtime.

Why not just look the target up

A config-bundle test has no target of its own to substitute:

• Its variants carry configurationBundle ARNs, and the schema forbids target on them (target: z.never().optional()).
• It attaches to the whole gateway — the service splits traffic with a gateway rule keyed on the bundles, which is why the execution role is granted CreateGatewayRule/UpdateGatewayRule.
• Confirmed against the service: every config-bundle test in a live account stores only configurationBundle per variant, and e2e-tests/ab-test-config-bundle.test.ts creates one on a gateway with no targets at all — it reaches RUNNING fine.

So the path segment is whichever gateway target the caller chooses to invoke. The CLI cannot know it, and a gateway may have several targets fronting one runtime (a canary beside prod), where each is equally valid.

Change

Report the gateway base URL and name what to append, instead of guessing a path that 404s:

Gateway URL: https://<gatewayId>.gateway.bedrock-agentcore.<region>.amazonaws.com
  → append /<gateway-target>/invocations (see `agentcore status --json`)

Target-based tests are unchanged — their variants are targets, so variants[0].targetName is a real path and they keep a complete Invocation URL.

getInvocationUrl stays synchronous and pure, so all three call sites (view --json, printABTestDetail, the TUI detail view) pick this up with no plumbing changes.

Also corrects two comments that documented the bug as intended behaviour:

• docs/ab-tests.md — "config-bundle uses the agent name"
• RunABTestFlow.tsx — claimed targets deploy as ${project}-${target}; the L3 CDK deploys each target under its spec name verbatim (Gateway.ts), which is what makes the spec name the URL path segment.

--json shape change

For config-bundle tests only, invocationUrl is replaced by gatewayUrl + invocationUrlHint:

// before — a URL that 404s
{ "invocationUrl": "https://<gw>.../CustomerSupportAB/invocations" }

// after
{ "gatewayUrl": "https://<gw>...",
  "invocationUrlHint": "append /<gateway-target>/invocations (see `agentcore status --json`)" }

This is deliberate: a script reading .invocationUrl now gets nothing rather than a URL that silently fails. Target-based output is untouched. Both docs pages are updated.

Testing

• 419 test files / 6005 tests pass; tsc clean; eslint/prettier/secretlint clean.
• 8 tests on the changed code, including a regression asserting the URL never contains the runtime name, and that the config-bundle detail view prints no Invocation URL: line.
• Verified end-to-end through a bundled + globally installed build (npm run bundle → npm i -g) for both modes, in --json and in the TUI (direct view ab-test <id> and via the interactive list). Config-bundle detail view:

Gateway: arn:aws:bedrock-agentcore:us-west-2:...:gateway/my-gateway-secure-abc123
Gateway filter: none
Gateway URL: https://my-gateway-secure-abc123.gateway.bedrock-agentcore.us-west-2.amazonaws.com
  → append /<gateway-target>/invocations (see `agentcore status --json`)

Notes for reviewers

Two things I found while investigating but did not change, happy to file separately:

• docs/ab-tests.md documents --max-duration-days and --traffic-header, but neither flag is registered in run/command.tsx and CreateABTestOptions has no field for either.
• --gateway-filter scopes a config-bundle test to a target path (live tests do carry {"targetPaths":["/orders/*"]}). A future refinement could use a literal filter path as the printed URL's segment, but glob patterns make that ambiguous so I left it out.

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[github-actions]

Package Tarball

aws-agentcore-0.25.0.tgz

How to install

gh release download pr-1874-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.25.0.tgz

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	40.46%	15123 / 37373
🔵	Statements	39.72%	16123 / 40582
🔵	Functions	34.67%	2591 / 7472
🔵	Branches	33.83%	10079 / 29786

Generated in workflow #4279 for commit a71f153 by the Vitest Coverage Report Action

[notgitika]

This always returns only the gateway base URL. This breaks working same-name configurations and scripts consuming .invocationUrl, while leaving issue #1854’s workflow manual. Creation already loads gateway targets and runtime mappings, so it should emit a complete URL when one target uniquely matches, and expose candidates or a clear ambiguity when several match.

[jariy17]

I was thinking of this but I wanted to establish to the user that config bundles are applied to all gateway targets. However, I could go either with this.

[notgitika]

left a comment otherwise LGTM

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)