Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Harness deploy fails: CLI-generated API-key credential provider names use underscores, which ApiKeyArn rejects

已关闭 适合新手
  • 哪里不对？
#2,546 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
82/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
typescript
领域
cli

调研方向

从 providerName() 开始，位置在 src/core/project/backends/cdk/credentials.ts:44，追踪该名称如何被组装进为 AWS::BedrockAgentCore::Harness 输出的 ApiKeyArn，以及 agentcore status 和 deploy 如何把它读回来。先与维护者确定修复方向（改分隔符 vs. 仅 sanitize ARN 片段），因为重命名会影响已经部署的 providers。当 issue 中的复现步骤 —— 先添加 credentials，再添加一个引用所报 ARN 的 harness —— 通过 deploy 的早期校验，且现有 provider 名称仍能解析时，即为完成。

由索引模型根据 Issue 内容生成。

描述

bug
What happens

A harness that uses an API-key model provider (OpenAI or Gemini) cannot be deployed when its apiKeyArn points at a credential provider the CLI created. The deploy fails CloudFormation's early validation:

Error: ❌  AgentCore-<project>-default failed: DeploymentError: Early validation failed for change set cdk-deploy-change-set:
AgentCore-<project>-default/Application/HarnessGeminiHarness/Harness/Resource  (AWS::BedrockAgentCore::Harness ...)
  Property value
  [arn:aws:bedrock-agentcore:us-east-1:<account>:token-vault/default/apikeycredentialprovider/<project>_default_GeminiKey]
  does not match pattern:
  ^arn:aws(-[^:]+)?:bedrock-agentcore:[a-z0-9-]+:[0-9]{12}:token-vault/[a-zA-Z0-9-.]+/apikeycredentialprovider/[a-zA-Z0-9-.]+$
  (at /Resources/.../Properties/Model/GeminiModelConfig/ApiKeyArn)
Why

providerName() in src/core/project/backends/cdk/credentials.ts:44 builds the Identity provider name as:

return `${projectName}_${targetName}_${credentialName}`;

CreateApiKeyCredentialProvider accepts those underscores, so the provider is created fine and agentcore status reports it as deployed. But the ApiKeyArn property on AWS::BedrockAgentCore::Harness only allows [a-zA-Z0-9-.]+ in the provider segment, so the same ARN is rejected when a harness references it. The two sides disagree on the allowed character set.

Impact

Any open_ai or gemini harness wired to a CLI-managed credential fails to deploy. The failure comes at deploy time, after the credential provider has already been created in the account.

Reproduce
agentcore create --name repro
cd repro
agentcore add credentials api-key --name GeminiKey --api-key file://./key.txt
agentcore deploy          # creates the provider: repro_default_GeminiKey
agentcore add harness --name GeminiHarness \
  --model '{"provider":"gemini","modelId":"gemini-3.8-flash","apiKeyArn":"<the ARN from agentcore status>"}'
agentcore deploy          # fails early validation on ApiKeyArn

Confirmed it's the underscores: creating a provider named dashtest-geminikey by hand and pointing the same harness at that ARN deploys successfully.

Possible fixes
  • Use a separator the harness pattern accepts (e.g. -) in providerName(). This renames providers, so it needs a migration path for projects that already deployed.
  • Or sanitize only what goes into the ARN, and keep the existing name for providers already out there.
  • Either way, validating the ARN shape in the CLI before deploy would turn this into an upfront error instead of a CloudFormation failure.
Environment
  • CLI built from refactor (v1.0.0-rc.5 line)
  • Region us-east-1, commercial partition
主要语言
TypeScript
星标
304
派生
105
平均合并
16 小时 45 分钟
30 天内合并 PR
168

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

aws/agentcore-cli 的其他 Issue

查看 aws/agentcore-cli 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。