Skip to content

TypeRegistry breaks when multiple versions of @smithy/core exist at runtime #1930

@haydenbaker

Description

@haydenbaker

Description

  • When two copies of @smithy/core exist at runtime, multiple "singleton" instances of the type-registry may exist
  • A client might register errors in one, but deserialization may use another instance
  • If that is the case, the errors will never resolve, so the client will always return a generic Error instance instead of an instance of the real error (e.g. ResourceNotFound)

Notes

  • TypeRegistry state is stored in a static field, which makes it a per-module singleton rather than a per-process singleton
  • If two copies of @smithy/core (in our case, 3.23.8 and 3.23.9), Node loads them as separate modules and each gets its own registry
    • In the case of one of our projects, the dependencies look like:
  @aws-sdk/client-s3@3.999.0 -> @aws-sdk/core@3.973.17 -> @smithy/core@3.23.8
  @aws-sdk/client-sqs@3.999.0 -> @aws-sdk/core@3.973.19 -> @smithy/core@3.23.9
  @stedi/sdk-client-xyz
    -> @smithy/core: ^3.23.2       // resolves to hoisted 3.23.8
    -> @aws-sdk/core: ^3.973.11    // resolves to hoisted 3.973.19
         -> @smithy/core: ^3.23.9  // resolves to nested 3.23.9
- `npm` hoists one and nests the other, and our generated ts client uses the former (`@smithy/core@3.23.8`) to register the errors, but then the deserialization path uses the latter (`@smithy/core@3.23.9`), registry instances are different

Reproduction

Metadata

Metadata

Assignees

Labels

closing-soonThis issue will automatically close in 2 days unless further comments are made.releasedThe change has been released and there is a comment with the release version.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions