fix: handle clientContextParam collisions with builtin config keys #1788

smilkuri · 2025-11-24T16:07:30Z

Issue #, if available:

Description of changes:

This fixes TypeScript client codegen conflict between known config keys and clientContextParams by adding the nested clientContextParams object to isolate conflicting parameters while maintaining backward compatibility and proper precedence.

--

packages/middleware-endpoint/src/adaptors/getEndpointFromInstructions.ts

packages/middleware-endpoint/src/adaptors/createConfigValueProvider.ts

...est/java/software/amazon/smithy/typescript/codegen/endpointsV2/EndpointsV2GeneratorTest.java

.changeset/stale-phones-behave.md

...rc/main/java/software/amazon/smithy/typescript/codegen/endpointsV2/EndpointsV2Generator.java

private/my-local-model-schema/src/endpoint/EndpointParameters.ts

packages/middleware-endpoint/src/adaptors/createConfigValueProvider.ts

kuhe · 2025-12-02T16:38:09Z

packages/middleware-endpoint/src/adaptors/createConfigValueProvider.ts

+    if (isClientContextParam) {
+      // For client context parameters, check clientContextParams first
+      const clientContextParams = config.clientContextParams as Record<string, unknown> | undefined;
+      const nestedValue: unknown = clientContextParams?.[configKey] ?? clientContextParams?.[canonicalEndpointParamKey];


is there any case where the nested object does not use the canonical parameter key?

If not, there's no reason to check the configKey entry for the nested object.

I don't think so

packages/middleware-endpoint/src/adaptors/getEndpointFromInstructions.ts

kuhe · 2025-12-02T16:46:06Z

private/my-local-model/src/endpoint/EndpointParameters.ts

  options: T & ClientInputEndpointParameters
 ): T & ClientResolvedEndpointParameters => {
  return Object.assign(options, {
+    apiKey: options.apiKey ?? "default-api-key",


This is the main point of the fix, but this shouldn't appear here, since it will conflict with the same key potentially be added by the api key auth scheme.

This is generated because the parameter has a default value set defined in @endpointRuleSet. If a default value is not defined it doesn't generate this.

that does not matter - a conflicting key cannot be generated here

private/my-local-model/src/endpoint/ruleset.ts

...rc/main/java/software/amazon/smithy/typescript/codegen/endpointsV2/EndpointsV2Generator.java

kuhe · 2025-12-02T17:19:17Z

smithy-typescript-protocol-test-codegen/model/my-local-model/main.smithy

 @documentation("xyz interfaces")
+@clientContextParams(
+    apiKey: { type: "string", documentation: "API key for authentication" }
+    customParam: { type: "string", documentation: "Custom parameter" }


going to comment again here since this is the source file and ruleset.ts is generated:

add some more client context params with varying permutations:

conflicting / non-conflicting

string / string[] / boolean

has default + required / no default + optional

kuhe · 2025-12-05T16:21:25Z

packages/eventstream-serde-universal/src/eventstream-cbor.integ.spec.ts

      endpoint: "https://localhost",
-    });
+      apiKey: { apiKey: "test-api-key" },
+    } as any);


there should be no as any here. This test is from a user perspective (integ test means calls user-facing public APIs only), so the types must align with the user intention.

kuhe · 2025-12-05T16:24:25Z

packages/middleware-endpoint/src/adaptors/createConfigValueProvider.spec.ts

+    const config = {
+      apiKey: "direct-api-key",
+      clientContextParams: {
+        apiKey: "nested-api-key",


Although conflicts don't matter at the unit level (and this code is not aware of what is considered a conflict),

change this test key to something else that doesn't conflict, like stage: string = "beta" | "prod". This implies that apiKey is a string at the base config level, but it isn't (when present).

packages/middleware-endpoint/src/adaptors/createConfigValueProvider.spec.ts

kuhe · 2025-12-05T16:26:30Z

packages/util-retry/src/retries.integ.spec.ts

      endpoint: "https://localhost/nowhere",
-    });
+      apiKey: { apiKey: "test-api-key" },
+    } as any);


remove as any

If I removed any it was throwing a type incompatibility error.

kuhe · 2025-12-05T16:27:50Z

private/my-local-model-schema/src/auth/httpAuthSchemeProvider.ts

+  type Provider,
+  ApiKeyIdentity,
+  ApiKeyIdentityProvider,
+  HttpApiKeyAuthLocation,


these new imports look like types. Change the codegen part to use addTypeImport() instead, or if imported via symbol, ensure the symbol has the typeOnly property.

kuhe · 2025-12-05T16:34:49Z

private/my-local-model-schema/src/endpoint/EndpointParameters.ts

+  customParam: "default-custom-value",
+  debugMode: false,
+  enableFeature: true,
+} as const;


I realized that this set of defaults cannot be the full set of clientContextParams that have default values.

For example, consider a non-conflicting clientContextParam stage with default of "prod". The user may instantiate like this:

new Client({ stage: "prod" });

but because the default value is written to the nested property, it will take precedence.

new Client({ stage: "beta" // <- set by user clientContextParams: { stage: "prod" // <- set by default, but higher priority } });

Therefore, this set of defaults must only be the conflicting clientContextParam defaults. In such cases, the default value applied at the root config level will take care of setting the correct default value.

const resolvedConfig = { stage: "prod", // set by resolveClientEndpointParameters as default conflictingParam: "(any)", // conflicting param may have separate default clientContextParams: { stage: undefined // no default needs to be assigned here conflictingParam: "conflictingParamDefault" // do set values for conflicting params } }

Please also add an integration test for this scenario.

Makes sense. Will modify.

kuhe · 2025-12-05T16:36:05Z

private/my-local-model-schema/src/endpoint/EndpointParameters.ts

 * @internal
 */
 export const commonParams = {
+  ApiKey: { type: "clientContextParams", name: "apiKey" },


wasn't there an automatic conversion of the param name to camelCase in the endpoints generator? If it couldn't find an existing built-in name.

kuhe · 2025-12-05T16:36:45Z

private/my-local-model-schema/src/endpoint/EndpointParameters.ts

 */
 export interface EndpointParameters extends __EndpointParameters {
-  endpoint?: string | undefined;
+  endpoint: string;


not saying it's wrong necessarily, but why did endpoint become required in the change?

kuhe · 2025-12-05T16:37:45Z

private/my-local-model/src/auth/httpAuthExtensionConfiguration.ts

@@ -1,5 +1,5 @@
 // smithy-typescript generated code
-import type { HttpAuthScheme } from "@smithy/types";
+import { type HttpAuthScheme, ApiKeyIdentity, ApiKeyIdentityProvider } from "@smithy/types";


change these to type imports

kuhe · 2025-12-05T16:38:02Z

private/my-local-model/src/auth/httpAuthSchemeProvider.ts

+  type Provider,
+  ApiKeyIdentity,
+  ApiKeyIdentityProvider,
+  HttpApiKeyAuthLocation,


use type imports

smilkuri force-pushed the resolve-conflict-params branch from 4a0b1ea to c0cc0c7 Compare November 26, 2025 16:57

smilkuri mentioned this pull request Nov 26, 2025

chore(codegen): generate corresponding clients for conflict params aws/aws-sdk-js-v3#7527

Closed

smilkuri force-pushed the resolve-conflict-params branch from f3ea1fe to 13fd0f0 Compare December 1, 2025 16:16

smilkuri marked this pull request as ready for review December 1, 2025 16:57

smilkuri requested a review from a team as a code owner December 1, 2025 16:57

smilkuri force-pushed the resolve-conflict-params branch 2 times, most recently from 9117008 to 1fc37f8 Compare December 1, 2025 17:01

smilkuri changed the title ~~fix: nest conflicting endpoint parameters~~ fix: handle clientContextParam collisions with builtin config keys Dec 1, 2025

kuhe requested changes Dec 1, 2025

View reviewed changes

smilkuri force-pushed the resolve-conflict-params branch from ef3cda8 to c5f0d86 Compare December 1, 2025 20:11

kuhe reviewed Dec 1, 2025

View reviewed changes

...rc/main/java/software/amazon/smithy/typescript/codegen/endpointsV2/EndpointsV2Generator.java Outdated Show resolved Hide resolved

kuhe reviewed Dec 1, 2025

View reviewed changes

...rc/main/java/software/amazon/smithy/typescript/codegen/endpointsV2/EndpointsV2Generator.java Outdated Show resolved Hide resolved

kuhe reviewed Dec 1, 2025

View reviewed changes

...rc/main/java/software/amazon/smithy/typescript/codegen/endpointsV2/EndpointsV2Generator.java Outdated Show resolved Hide resolved

kuhe reviewed Dec 1, 2025

View reviewed changes

private/my-local-model-schema/src/endpoint/EndpointParameters.ts Show resolved Hide resolved

kuhe reviewed Dec 2, 2025

View reviewed changes

smilkuri force-pushed the resolve-conflict-params branch 3 times, most recently from 9f47441 to 1ed724d Compare December 4, 2025 18:09

smilkuri added 8 commits December 5, 2025 15:35

fix: nest conflicting endpoint parameters

13a1bca

fix: add fallback resolution

f2c3c14

chore: fix formatting and add changeset

1d493e5

chore: address comments and add diff for build generate-protocol-tests

d0657db

fix: add isClientContextParam flag to handle parameter types

6dc79b1

chore: refactor code and add custom ruleset

c81cf3d

chore: make code cleaner

c453d61

chore: fix failing integ tests

182326a

smilkuri force-pushed the resolve-conflict-params branch from 1ed724d to 182326a Compare December 5, 2025 15:55

smilkuri mentioned this pull request Dec 5, 2025

chore: codegen changes for handling conflicting params aws/aws-sdk-js-v3#7549

Open

kuhe reviewed Dec 5, 2025

View reviewed changes

fix: handle clientContextParam collisions with builtin config keys #1788

Are you sure you want to change the base?

fix: handle clientContextParam collisions with builtin config keys #1788

Uh oh!

Conversation

smilkuri commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

smilkuri commented Nov 24, 2025 •

edited

Loading