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

  1. 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.
  2. Against real AWS, verify the credentials/region and retry; capture the raw CreateKey response to confirm whether metadata is being dropped.
  3. Update the aws-sdk-kms crate version in Cargo.toml if a serialization bug is suspected.
  4. 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

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.