feat(core): pass client logger to request handlers by aBurmeseDev · Pull Request #2170 · smithy-lang/smithy-typescript

aBurmeseDev · 2026-07-21T08:23:15Z

Issue #, if available:
aws/aws-sdk-js-v3#6130
JS-7027

Description of changes:

Passes the client's logger to request handlers as a fallback. Handlers use it for socket exhaustion warnings and timeout messages only if they don't already have their own logger. When the client logger is a NoOpLogger, the call is skipped entirely, so handlers keep their console defaults when the client hasn't configured logging.

Also fixes a latent bug in httpExtensionConfig.ts where getHttpHandlerExtensionConfig and resolveHttpHandlerRuntimeConfig were reading/writing runtimeConfig.httpHandler which clients never populate. Changed to requestHandler. Both affected types are @internal.

Testing

unit tests for logger injection in getHttpHandlerExtensionConfig
unit tests for NodeHttpHandler.updateHttpClientConfig nullish
unit tests for UndiciHttpHandler.updateHttpClientConfig

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

TypeScript strict mode cannot narrow `value` from the full `NodeHttpHandlerOptions[typeof key]` union when branching on `key === "logger"`. Add an explicit cast to fix the build:types target in CI.

kuhe

look at additional requestHandler implementations in AWS SDK JS.

at this time, handlers which resolve config asynchronously don't offer a way to query whether there is a higher priority logger set on the requestHandler at requestHandler initialization.

We need a plan to account for this problem.

kuhe · 2026-07-30T20:47:45Z

  runtimeConfig: HttpHandlerExtensionConfigType<HandlerConfig>
 ) => {
+  if ((runtimeConfig as any).logger) {
+    runtimeConfig.httpHandler?.updateHttpClientConfig("logger" as keyof HandlerConfig, (runtimeConfig as any).logger);


This is an unconditional overwrite of the handler logger with the client logger, which is not always intended.

Here are the design requirements:

H = handler, C = client

if H has no explicit logger and C has a logger (default or otherwise), provide C logger to H logger

in other words, if H has an explicit logger, do not overwrite it

if H resolves its logger asynchronously (NodeHttpHandler), it must still accept the C logger synchronously and save it for later use.

the system must work with all 5 team-authored hanlders: Fetch, Node, Undici, Xhr, and WebsocketFetch

no handler level method should be added, such as setFallbackLogger(Logger).

We may want to customize updateHttpClientConfig implementations in all 5 handlers such that receiving a special key sets the fallback logger, but do not define this key on the public input config of the handler itself.

Example:

updateHttpClientConfig(key: symbol, value: unknown): void; updateHttpClientConfig(key: keyof XhrHttpHandlerOptions, value: XhrHttpHandlerOptions[typeof key]): void;

The client now passes its logger to the request handler through updateHttpClientConfig, under a new FALLBACK_LOGGER key exported from @smithy/core/protocols

node-http-handler uses it for its socket exhaustion and request timeout warnings when it has no logger of its own, replacing config.logger ?? console with config.logger ?? fallbackLogger

found that this never actually runs, the client offers its logger but updateHttpClientConfig call is skipped. I think it's because getHttpHandlerExtensionConfig expects the handler at runtimeConfig.httpHandler but clients populate requestHandler instead. And since httpHandler is never set, the guard httpHandler?. on updateHttpClientConfig skips the call entirely. Should it move to a point that actually reads requestHandler?

getHttpHandlerExtensionConfig and resolveHttpHandlerRuntimeConfig now use requestHandler (the field clients actually set) instead of httpHandler (which was always undefined)

This was already broken where runtimeConfig.httpHandler! non-null assertion has been silently reading undefined since it was introduced. Nothing surfaced it because nothing called these methods until now.

Both HttpHandlerExtensionConfigType and resolveHttpHandlerRuntimeConfig return type change shape but both are @internal. Noted in the changeset.

aBurmeseDev · 2026-08-07T07:32:42Z

+    value: FetchHttpHandlerOptions[keyof FetchHttpHandlerOptions] | Logger
+  ): void {
+    if (key === FALLBACK_LOGGER) {
+      this.fallbackLogger = value as Logger;


fallbackLogger gets set here but isn't referenced anywhere else, same for undici. Only node-http-handler consumes it.

kuhe · 2026-08-07T19:14:44Z

+  /**
+   * Client logger, used only when this handler has no logger of its own.
+   */
+  private fallbackLogger?: Logger;


don't use a separate field. the logger can be assigned if receiving a fallback logger and no logger exists

fallbackLogger field removed, now assigns directly into config.logger.

kuhe · 2026-08-07T19:29:48Z

+ *
+ * @internal
+ */
+export const FALLBACK_LOGGER: unique symbol = Symbol.for("smithy.httpHandler.fallbackLogger");


Symbol.for is the opposite of unique. Remove the unique type keyword here.

done, now Symbol.for("logger") with no unique.

kuhe · 2026-08-07T19:30:14Z

+   *
+   * The key may also be {@link FALLBACK_LOGGER}, with which a client offers its
+   * logger for use only when the handler has no logger of its own. Handlers
+   * that predate that key ignore it.


description goes first, above the @internal annotation

kuhe · 2026-08-07T19:32:06Z

+   * that predate that key ignore it.
   */
-  updateHttpClientConfig(key: keyof HttpHandlerConfig, value: HttpHandlerConfig[typeof key]): void;
+  updateHttpClientConfig(


don't change the signature of this method, I believe this could be breaking for consuming implementers.

reverted. The fallback logger key is now handled at each handler's call site.

kuhe · 2026-08-07T19:33:40Z

 export { Field } from "./protocol-http/Field";
 export { Fields, type FieldsOptions } from "./protocol-http/Fields";
 export { type HttpHandler, type HttpHandlerUserInput } from "./protocol-http/httpHandler";
+export { FALLBACK_LOGGER } from "./protocol-http/fallbackLogger";


let's not export this, Symbol.for("string") can be equality-compared across contexts.

The value can be Symbol.for("logger"), since being a symbol is already differentiated from "logger" as a normal string.

no longer exported. Each handler declares its own Symbol.for("logger") now.

kuhe · 2026-08-10T16:59:48Z

+ *
+ * @internal
+ */
+const FALLBACK_LOGGER: symbol = Symbol.for("logger");


inline this

inlined in both handlers.

Also inlined it at the offer site in httpExtensionConfig.ts which let me drop fallbackLogger.ts entirely since it only existed to export that one.

…r.ts

aBurmeseDev

recap for reviewers:
passes the client's logger to request handlers as a fallback. Handlers use it for socket exhaustion warnings and timeout messages only if they don't already have their own logger. When the client logger is a NoOpLogger, the call is skipped entirely, so handlers keep their console defaults when the client hasn't configured logging.

Also fixes a latent bug in httpExtensionConfig.ts where getHttpHandlerExtensionConfig and resolveHttpHandlerRuntimeConfig were reading/writing runtimeConfig.httpHandler which clients never populate. Changed to requestHandler. Both affected types are @internal.

FetchHttpHandlerOptions has no logger field and the handler doesn't log anything. So fetch-http-handler is unchanged. If we want consistency across, I can add a logger field to FetchHttpHandlerOptions as a public option.

feat(node-http-handler): pass client logger to request handlers

bd1691b

aBurmeseDev requested a review from a team as a code owner July 21, 2026 08:23

aBurmeseDev and others added 2 commits July 21, 2026 01:29

Merge branch 'main' into feat/pass-client-logger-to-request-handler

65f4a95

fix: cast logger value type in updateHttpClientConfig

6671898

TypeScript strict mode cannot narrow `value` from the full `NodeHttpHandlerOptions[typeof key]` union when branching on `key === "logger"`. Add an explicit cast to fix the build:types target in CI.

aBurmeseDev marked this pull request as draft July 23, 2026 17:46

simplify logger injection per team decision

418fa74

aBurmeseDev changed the title ~~feat(node-http-handler): pass client logger to request handlers~~ feat(core): pass client logger to request handlers Jul 24, 2026

Merge branch 'main' into feat/pass-client-logger-to-request-handler

687f8e3

aBurmeseDev marked this pull request as ready for review July 24, 2026 06:23

trivikr reviewed Jul 24, 2026

View reviewed changes

Comment thread packages/core/src/submodules/protocols/protocol-http/extensions/httpExtensionConfiguration.ts Outdated

trivikr reviewed Jul 24, 2026

View reviewed changes

Comment thread packages/undici-http-handler/src/undici-http-handler.spec.ts Outdated

kuhe reviewed Jul 24, 2026

View reviewed changes

Comment thread packages/core/src/submodules/protocols/protocol-http/extensions/httpExtensionConfiguration.ts Outdated

kuhe reviewed Jul 24, 2026

View reviewed changes

Comment thread packages/node-http-handler/src/node-http-handler.ts

kuhe requested changes Jul 24, 2026

View reviewed changes

remove nullish assignments and add truthy check

a43865a

aBurmeseDev requested review from kuhe and trivikr July 24, 2026 22:51

Merge branch 'main' into feat/pass-client-logger-to-request-handler

8833c39

kuhe reviewed Jul 30, 2026

View reviewed changes

aBurmeseDev and others added 5 commits August 3, 2026 10:25

feat(core): offer client logger to request handlers as a fallback

6f96ae3

test: cover fallback logger in handler specs

203c84e

chore: record fallbackLogger in API snapshot

25212ad

Merge branch 'main' into feat/pass-client-logger-to-request-handler

0609b70

Merge branch 'main' into feat/pass-client-logger-to-request-handler

ada1408

aBurmeseDev commented Aug 7, 2026

View reviewed changes

kuhe reviewed Aug 7, 2026

View reviewed changes

aBurmeseDev and others added 3 commits August 8, 2026 19:04

fix: read requestHandler in http handler extension config

d84a219

fix: drop stale api snapshot entries from bad merge

6c73415

Merge branch 'main' into feat/pass-client-logger-to-request-handler

4f81d14

kuhe reviewed Aug 10, 2026

View reviewed changes

aBurmeseDev added 2 commits August 11, 2026 01:34

refactor: inline the fallback logger key in handlers

9f3f1ee

refactor(core): inline the fallback logger key and drop fallbackLogge…

fc65973

…r.ts

aBurmeseDev commented Aug 11, 2026

View reviewed changes

kuhe approved these changes Aug 12, 2026

View reviewed changes

Merge branch 'main' into feat/pass-client-logger-to-request-handler

0fe930f

siddsriv approved these changes Aug 12, 2026

View reviewed changes

Uh oh!

Conversation

aBurmeseDev commented Jul 21, 2026 • 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!

kuhe left a comment

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!

aBurmeseDev Aug 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aBurmeseDev left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

aBurmeseDev commented Jul 21, 2026 •

edited

Loading

aBurmeseDev Aug 9, 2026 •

edited

Loading

aBurmeseDev left a comment •

edited

Loading