Generated client does not add headers resolved from Endpoint Ruleset to the request

[humanzz]

Hello,

I'm using typescript-client-codegen plugin to generate a typescript client for a model where I use https://smithy.io/2.0/additional-specs/rules-engine/specification.html to add stage and apiKey client context parameters so that my service's client users can have an easy way of selecting the service's endpoint based on stage, and also to set the apiKey I provide for them.

For the generated typescript client, and despite setting the apiKey which should, in the case of the model below, lead to the selection of an endpoint configuration that has the x-api-key header being set to the value of the apiKey provided, the final outgoing request never has that header set.

For context, I'm generating an AWS SDK v2-based client (starting from Smithy -> C2J -> generated Java Client, so I know it's a bit different), and following the same approach I'm able to set the apiKey on the client, and the endpoint header is included in the outgoing request.

I tried debugging the generated typescript client, and I could see that

• Till

  smithy-typescript/packages/middleware-endpoint/src/endpointMiddleware.ts

  Line 57 in a0e0035

  context.endpointV2 = endpoint;

  , the endpoint is resolved correctly, and has the x-api-key header
• I suspect it's in

  smithy-typescript/packages/core/src/submodules/protocols/requestBuilder.ts

  Line 33 in a0e0035

  const { hostname, protocol = "https", port, path: basePath } = await this.context.endpoint();

  where the HttpRequest is created, ignoring the headers from the endpoint

Is that an intentional behavior? If not, then this is a feature request to respect the endpoint headers.

$version: "2.0"

namespace software.MyService

use smithy.rules#clientContextParams
use smithy.rules#endpointRuleSet
use smithy.rules#endpointTests

apply MyService @clientContextParams(
    Stage: { type: "string", documentation: "Service stage (beta|prod)" }
    ApiKey: { type: "string", documentation: "ApiKey" }
)

apply MyService @endpointRuleSet({
    version: "1.0"
    parameters: {
        Stage: { required: false, documentation: "Specify the stage (beta|prod) so the endpoint is automatically set. If unspecified, prod endpoint will be used. Setting an explicit endpoint override is supported.", type: "String" }
        ApiKey: { required: false, documentation: "ApiKey", type: "string" }
        Endpoint: { builtIn: "SDK::Endpoint", required: false, documentation: "Override the endpoint used to send requests", type: "String" }
    }
    rules: [
        // Rule to allow using endpoint overrides (with api key set)
        {
            type: "endpoint"
            conditions: [
                {
                    fn: "isSet"
                    argv: [
                        {
                            ref: "Endpoint"
                        }
                    ]
                }
                {
                    fn: "isSet"
                    argv: [
                        {
                            ref: "ApiKey"
                        }
                    ]
                }
            ]
            endpoint: {
                headers: {
                    "x-api-key": ["{ApiKey}"]
                }
                url: { ref: "Endpoint" }
            }
        }

...

[humanzz]

I think I have a slightly better understanding, and realization that there are a couple of issues at play.

First, I've so far been using the approach outlined in the Smithy model snippet above, to provide a user-friendly way, for my Java client users (The AWS SDK v2 client that goes Smithy -> C2J -> Java). With that approach, the client builder exposed MyService.builder().apiKey("the key").stage("the stage") setters. The endpoint selected, included the headers, which then got applied to the request.

For the TypeScript client (Smithy -> Typescript directly), I found a couple of things

1. If my service shape has @httpApiKeyAuth(name: "x-api-key", in: "header")
   • MyServiceClientConfig (the type of the arg to a new MyService(...)), gets an apiKey property that is apiKey?: ApiKeyIdentity | ApiKeyIdentityProvider; from
   • the generated HttpAuthSchemeInputConfig defines an apiKey property that is apiKey?: ApiKeyIdentity | ApiKeyIdentityProvider;
   • the generated ClientInputEndpointParameters, with @clientContextParams defining an ApiKey parameter that's a string, defines an apiKey?: string | undefined | Provider<string | undefined>;
   • MyServiceClientConfig ends up extending both HttpAuthSchemeInputConfig and ClientInputEndpointParameters which leads to the definition of apiKey? being unsatisfiable
2. If no @httpApiKeyAuth(name: "x-api-key", in: "header"),

• a single apiKey? definition is added to MyServiceClientConfig (that comes from ClientInputEndpointParameters)
• HttpApiKeyAuthSigner won't be applied, and therefore it won't set the header
• Different from the Java Client, and as reported earlier, despite the @endpointRuleSet returning an endpoint with headers, those headers are ignored and are not applied to the request

Now, all of this leads me to think

1. There's a general issue in typescript client codegen where it ignores the headers of the endpoint selected from the @endpointRuleSet
2. I understand that, and pasting the C2J conversion warning, The smithy auth scheme smithy.api#httpApiKeyAuth is not supported in C2J auth conversion and will be filtered as the AWS SDK v2 does not support this as an auth mechanism, and that because of that, and its respect of endpoint headers, my model works for it
3. Smithy Typescript codegen on the other hand, supports smithy.api#httpApiKeyAuth, and with it it adds an apiKey to the client config, but in doing so, it makes it not possible to use the apiKey with @endpointRuleSet.

• At a bare minimum, there should've been an earlier error in the codegen, that apiKey is a reserved keyword, and that it cannot be used in @clientContextParams
• Better, apiKey can still be defined in @clientContextParams, and @endpointRuleSet parameters but in a manner which makes it compatible with smithy codegen's exposure of apiKey config property when using smithy.api#httpApiKeyAuth (not sure if builtIns might be some way for this)