feat: instrument telemetry for invoke command

[Hweinstock]

Description

Add telemetry instrumentation to the invoke command for all CLI execution paths using withCommandRunTelemetry.

As with other PRs for instrumenting telemetry, the main changes are refactoring to the error handling to avoid killing the process before telemetry can be emitted.

Related Issue

Closes #

Documentation PR

N/A

Type of Change

• New feature

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint

Additional testing:

• Added telemetry assertions to all existing invoke tests (validation, agent validation, streaming)
• Added new test cases for --bearer-token (auth_type) and --session-id (has_session_id)
• 7/7 invoke tests pass with telemetry assertions

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Package Tarball

aws-agentcore-0.13.1.tgz

How to install

npm install https://github.com/aws/agentcore-cli/releases/download/pr-1227-tarball/aws-agentcore-0.13.1.tgz

[agentcore-cli-automation]

LGTM 👍

Reviewed the changes against the telemetry README and the deploy command's pattern. The PR:

• Correctly wraps both CLI and TUI paths with withCommandRunTelemetry('invoke', ...), including validation/prompt-resolution failures (these now emit exit_reason: 'failure' instead of being skipped).
• Properly refactors handleInvokeCLI to return InvokeResult so telemetry can be recorded before output/exit, and extracts printInvokeResult to keep the I/O concerns in the action handler.
• As a side-benefit, switches JSON output to use serializeResult, fixing the latent bug where a failure result's error would have serialized as {} (Error has non-enumerable props).
• Tests use real subprocess + temp dirs + audit-mode telemetry helper — no excessive mocking.

A few small things I considered and decided weren't worth blocking on:

• loadInvokeConfig is now called twice on the CLI path (once up-front for the protocol attribute, once inside handleInvokeCLI). Local file reads, fine.
• TUI mode always records exit_reason: 'success' since the callback returns {success: true} after waitUntilExit. Per-invoke failures inside an interactive session aren't captured, but that's consistent with one command_run metric per command invocation.
• A bad -H value would throw from parseHeaderFlags before the telemetry wrapper runs and skip the metric, but that matches existing behavior.

[Hweinstock]

loadInvokeConfig is now called twice on the CLI path (once up-front for the protocol attribute, once inside handleInvokeCLI). Local file reads, fine.

feels worth addressing.

TUI mode always records exit_reason: 'success' since the callback returns {success: true} after waitUntilExit. Per-invoke failures inside an interactive session aren't captured, but that's consistent with one command_run metric per command invocation.

I think this is the behavior we want. We may one day want separate telemetry for the individual invocations.

A bad -H value would throw from parseHeaderFlags before the telemetry wrapper runs and skip the metric, but that matches existing behavior.

worth addressing and making it a validation exception.