Why is @aws-sdk/node-http-handler suddenly deprecated?

[jhuckaby]

The @aws-sdk/node-http-handler package has become deprecated as of version 3.374.0, published on July 20, 2023:

https://www.npmjs.com/package/@aws-sdk/node-http-handler

Apparently it has now moved to the @smithy NPM org. What is @smithy?

Is this official? Do I need to change all my code now? Why would you move this module out of the @aws-sdk org?

Your own documentation still points to @aws-sdk/node-http-handler by the way:

https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/interfaces/_aws_sdk_node_http_handler.nodehttphandleroptions-1.html

Is this some kind of mistake, or is this an official change?

Thank you.

[jmtt89]

I have several packages with the same situation.

npm WARN deprecated @aws-sdk/hash-stream-node@3.374.0: This package has moved to @smithy/hash-stream-node
npm WARN deprecated @aws-sdk/url-parser@3.374.0: This package has moved to @smithy/url-parser
npm WARN deprecated @aws-sdk/protocol-http@3.374.0: This package has moved to @smithy/protocol-http
npm WARN deprecated @aws-sdk/hash-node@3.374.0: This package has moved to @smithy/hash-node

looks like a global change, but i don't find any information about that change :/

[kuhe]

Smithy is a language for defining services and SDKs. It is open source software maintained by AWS.

Smithy is used to generate both the AWS SDK for JavaScript v3, and other similar SDKs not necessarily related to AWS. Therefore, we decided to detach the AWS SDK namespace from core components used outside of AWS, such as the generic node http handler.

This is in effect a rename. Code examples and interfaces will continue to work with @smithy/* packages moved over from @aws-sdk/*.

@RanVaknin @srchase please create a pinned issue with any additional information you think is useful in answering questions related to this migration/renaming.

[VTLee]

Does the smithy code fall under the AWS side of the shared responsibility model for AWS customers?

Our group is concerned that by pushing this out of the AWS SDK, you're trying to absolve responsibility for errors with it (e.g. a compromised @smithy/node-http-handler) by pushing this into a code base that has a disclaimer on the first line of the README that says the code is not fully production ready.

[kuhe]

The statement you are referring to says the interfaces are subject to change and that the software is in a developer preview status. This refers primarily to the Java code generation component. The repository provides both the code generator as a Java library and the core runtime packages (@smithy/* on NPM).

The AWS SDK for JavaScript v3 uses Smithy TypeScript packages in production and is responsible for any dependencies it uses. You may report issues with the @smithy packages or any other dependency in the aws-sdk-js-v3 GitHub issues if they are impacting your use of the AWS SDK.

For @smithy/* packages, the AWS SDK team is code co-owner and contributor, so you will receive support identical to that for@aws-sdk/* packages.

[Biktop]

I would like to know if @smithy/* packages are installed in the latest Lambda container?

[jokalli2]

@Biktop looks like they aren't. I had to include AWS SDK again in the lambda package to be able to use NodeHttpHandler from the @smithy/node-http-handler package.

[praneetrattan]

@jokalli2 Can you please elaborate on this? Did you have to include all AWS SDK (client-dynamo, client-s3, etc.) packages or just @smithy/node-http-handler in your package.json? Are the rest of them still being loaded?
We are seeing a sudden issue where all aws-sdk-v3 packages which were getting loaded into the AWS env, are not getting loaded now? This was a sudden change that happened last night, and we have no code changes done to cause it. All we did was run the nightly job which redeploys services, and apparently there after aws-sdk packages were not available in the lambda env. And we are getting some weird error saying:

TypeError: _a.debug is not a function
    at _a (/var/runtime/node_modules/@aws-sdk/credential-provider-node/dist-cjs/index.js:69:50)
    at /var/runtime/node_modules/@aws-sdk/node_modules/@smithy/property-provider/dist-cjs/index.js:79:33
    at coalesceProvider (/var/runtime/node_modules/@aws-sdk/node_modules/@smithy/property-provider/dist-cjs/index.js:103:17)
    at /var/runtime/node_modules/@aws-sdk/node_modules/@smithy/property-provider/dist-cjs/index.js:124:24
    at /var/runtime/node_modules/@aws-sdk/node_modules/@smithy/core/dist-cjs/index.js:82:23```

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.

[tapz]

Started to see this error today with @aws-sdk/client-kms. Didn't deploy any new code or make changes to anywhere. This kind of things should not happen.

TypeError: _a.debug is not a function

[praneetrattan]

We had the same issue a month ago, and then again yesterday. All of a sudden this error started showing up. It seems to me, that AWS is updating their V3 SDK with minor changes, and then deploying them to environments. Even if you don't update your lambda, they will update the underlying V3 packages. If you don't want this, you have to send the V3 packages with your lambda (which poses a challenge with code size)

In our case, the error started showing up because when initialing a client, we use our own logger. And in that logger we had all levels of logging except debug. And this is old code! Then AWS went in and updated something on smithy, which called a .debug, and when it could not find that level on our logger, it threw this error. They could have easily thought this through and implemented a default level, in cases like these where debug is not provided.
Anyways, once we added a debug level to our custom logger, it started working fine!

[tapz]

We do have .debug in our logger, but still the change to the lambda runtime causes the lambda to crash. Clearly a kind of update AWS should NOT do.

[tapz]

I have already contacted the tech support, which we are paying for. This is totally unacceptable as this is a commercial platform, not some open source project.