Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: stop adding command mw repeatedly in resolveMiddleware() #1883

Merged
merged 1 commit into from
Jan 8, 2021

Conversation

AllanZhengYP
Copy link
Contributor

When sending the same command multiple times, resolveMiddleware()
will be called many times. So adding serde middleware will throw
error because they are already added into stack. This change
prevents adding the serde middleware repeatedly.

Alternative is moving command middleware to the command constructor,
just like in client(that's why client doesn't have the problem). But
the command middleware also have depdency over client configs
supplied from resolveMiddleware(). So serde middleware and
customizations must live here.

Fixes: #1864
Ref: smithy-lang/smithy-typescript#259

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

When sending the same command multiple times, resolveMiddleware()
will be called many times. So adding serde middleware will throw
error because they are already added into stack. This change
prevents adding the serde middleware repeatedly.

Alternative is moving command middleware to the command constructor,
just like in client(that's why client doesn't have the problem). But
the command middleware also have depdency over client configs
supplied from resolveMiddleware(). So serde middleware and
customizations must live here.

ref: aws#1864
@codecov-io
Copy link

Codecov Report

Merging #1883 (93a374e) into master (f2a47e8) will increase coverage by 0.52%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1883      +/-   ##
==========================================
+ Coverage   79.30%   79.83%   +0.52%     
==========================================
  Files         368      368              
  Lines       15132    15543     +411     
  Branches     3222     3364     +142     
==========================================
+ Hits        12001    12409     +408     
- Misses       3131     3134       +3     
Impacted Files Coverage Δ
packages/util-waiter/src/utils/validate.ts 81.81% <0.00%> (-18.19%) ⬇️
lib/storage/src/data-chunk/readable-helper.ts 88.23% <0.00%> (-4.08%) ⬇️
packages/util-dynamodb/src/convertToAttr.ts 98.70% <0.00%> (-1.30%) ⬇️
packages/util-waiter/src/waiter.ts 100.00% <0.00%> (ø)
protocol_tests/aws-ec2/endpoints.ts 81.48% <0.00%> (ø)
protocol_tests/aws-json/endpoints.ts 81.48% <0.00%> (ø)
protocol_tests/aws-query/endpoints.ts 81.48% <0.00%> (ø)
packages/util-dynamodb/src/marshall.ts 100.00% <0.00%> (ø)
protocol_tests/aws-restxml/endpoints.ts 81.48% <0.00%> (ø)
protocol_tests/aws-restjson/endpoints.ts 81.48% <0.00%> (ø)
... and 140 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 25cb359...93a374e. Read the comment docs.

@aws-sdk-js-automation
Copy link

AWS CodeBuild CI Report

  • CodeBuild project: sdk-staging-test
  • Commit ID: 93a374e
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@github-actions
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Can't reuse QueryCommand in loop
4 participants