FuelLabs/fuels-rs · error · anyhow::Error
key arn missing from response
Error message
key arn missing from response
What it means
Thrown in AwsKmsClient::create_signer (e2e KMS harness) when the AWS SDK CreateKey call succeeds but the returned KeyMetadata carries no ARN. The signer cannot be constructed because the key ARN is the identifier used for all subsequent signing requests.
Source
Thrown at e2e/src/aws_kms.rs:143
_container: testcontainers::ContainerAsync<AwsKmsImage>,
client: Client,
url: String,
}
impl AwsKmsProcess {
pub async fn create_signer(&self) -> anyhow::Result<AwsKmsSigner> {
let response = self
.client
.create_key()
.key_usage(KeyUsageType::SignVerify)
.key_spec(KeySpec::EccSecgP256K1)
.send()
.await?;
let id = response
.key_metadata
.and_then(|metadata| metadata.arn)
.ok_or_else(|| anyhow::anyhow!("key arn missing from response"))?;
let kms_signer = AwsKmsSigner::new(id.clone(), &self.client).await?;
Ok(kms_signer)
}
pub fn client(&self) -> &Client {
&self.client
}
pub fn url(&self) -> &str {
&self.url
}
}
View on GitHub (pinned to d9a250a518)
Solutions
- If using LocalStack/mock: update it to a version whose CreateKey response includes a full KeyMetadata.arn, or patch the mock to return the ARN.
- Against real AWS, verify the credentials/region and retry; capture the raw CreateKey response to confirm whether metadata is being dropped.
- Update the aws-sdk-kms crate version in Cargo.toml if a serialization bug is suspected.
- As a workaround in tests, construct AwsKmsSigner::new directly with a known existing key ARN instead of creating a fresh key.
Example fix
// before: relies on create_key response containing the ARN
let signer = client.create_signer().await?;
// after (workaround): import a pre-created key and skip create_key
let arn = std::env::var("TEST_KMS_KEY_ARN").expect("set TEST_KMS_KEY_ARN");
let signer = AwsKmsSigner::new(arn, client.client()).await?; Defensive patterns
Strategy: validation
Validate before calling
let resp = client.create_key().key_usage(KeyUsageType::SignVerify).key_spec(KeySpec::EccSecgP256K1).send().await?;
if resp.key_metadata.as_ref().and_then(|m| m.arn.as_ref()).is_none() {
anyhow::bail!("endpoint did not return a key ARN — is a LocalStack/mock KMS missing KeyMetadata.arn?");
} Try / catch
match client.create_signer().await {
Err(e) if e.to_string().contains("key arn missing") => {
// fall back to importing a pre-provisioned key ARN from the environment
let arn = std::env::var("TEST_KMS_KEY_ARN")?;
AwsKmsSigner::new(arn, client.client()).await
}
other => other,
} Prevention
- Run KMS e2e tests against LocalStack versions known to populate KeyMetadata.arn on CreateKey.
- Keep a pre-created ECC key's ARN in TEST_KMS_KEY_ARN as an import fallback for tests.
- Smoke-test create_key round-trips after any aws-sdk-kms or LocalStack version bump.
When it happens
Trigger: create_key() with KeyUsageType::SignVerify and KeySpec::EccSecgP256K1 returns a response whose key_metadata is None or whose arn field is None — typically against a KMS-compatible test endpoint (LocalStack/mock server, given the client carries a custom url) that does not populate KeyMetadata.arn, or an IAM/permission quirk returning a stripped response.
Common situations: Running the e2e AWS KMS tests against LocalStack or an in-process mock whose CreateKey implementation omits the ARN; version drift between the AWS SDK in use and the emulator's response shape; extremely rare against real AWS.
Related errors
AI-assisted analysis of FuelLabs/fuels-rs@d9a250a518 (2026-08-16).
Data as JSON: /api/errors/402937ffbd2396e1.
Report an issue: GitHub.