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

sqs.Client.TagQueue returns an error but still succeessfully tags a resource #1047

Closed
3 tasks done
artyom opened this issue Jan 15, 2021 · 5 comments · Fixed by #1050
Closed
3 tasks done

sqs.Client.TagQueue returns an error but still succeessfully tags a resource #1047

artyom opened this issue Jan 15, 2021 · 5 comments · Fixed by #1050
Assignees
Labels
bug This issue is a bug.

Comments

@artyom
Copy link

artyom commented Jan 15, 2021

Confirm by changing [ ] to [x] below to ensure that it's a bug:

Describe the bug

Attempts to tag an SQS queue with sqs.Client.TagQueue call fails with the following error:

operation error SQS: TagQueue, https response error StatusCode: 200, RequestID: 551b5c11-ecbd-55de-8d46-046a7bfc9c2d, deserialization failed, failed to decode response body, TagQueueResult node not found

API call actually succeeds, as provided tags appear on a resource.

Version of AWS SDK for Go?

0.31.0

Version of Go (go version)?

go version go1.16beta1 darwin/arm64

To Reproduce (observed behavior)

Steps to reproduce the behavior (please share code or minimal repo)

go.mod contents:

module sdk-bug

go 1.16

require (
	github.com/aws/aws-sdk-go-v2 v0.31.0
	github.com/aws/aws-sdk-go-v2/config v0.4.0
	github.com/aws/aws-sdk-go-v2/service/sqs v0.31.0
)

main.go contents:

package main

import (
	"context"
	"errors"
	"flag"
	"log"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/config"
	"github.com/aws/aws-sdk-go-v2/service/sqs"
)

func main() {
	log.SetFlags(0)
	flag.Parse()
	if err := run(context.Background(), flag.Arg(0)); err != nil {
		log.Fatal(err)
	}
}

func run(ctx context.Context, queueURL string) error {
	if queueURL == "" {
		return errors.New("provide a queue url to tag")
	}
	log.Println("SDK version:", aws.SDKVersion)
	cfg, err := config.LoadDefaultConfig(ctx)
	if err != nil {
		return err
	}
	svc := sqs.NewFromConfig(cfg)
	_, err = svc.TagQueue(ctx, &sqs.TagQueueInput{
		QueueUrl: &queueURL,
		Tags:     map[string]string{"Environment": "staging"},
	})
	return err
}

Build and run this program providing an SQS queue URL as a first positional argument.

Expected behavior

Program prints SDK version on stderr and finishes with 0 exit status. Resource is tagged.

Actual behavior

Program prints SDK version on stderr and finishes with non-zero exit status, printing an error:

operation error SQS: TagQueue, https response error StatusCode: 200, RequestID: 551b5c11-ecbd-55de-8d46-046a7bfc9c2d, deserialization failed, failed to decode response body, TagQueueResult node not found

Resource is tagged.

Additional context

Similar error happens with rds.Client.AddTagsToResource calls.

@artyom artyom added the bug This issue is a bug. label Jan 15, 2021
@jasdel
Copy link
Contributor

jasdel commented Jan 15, 2021

Thanks for reporting this issue. We're investigating this bug, and working on a solution. It looks like the SDK is attempting to deserialize a response when it shouldn't be. Will update this GitHub issue when a PR is created to fix this bug.

This issue will also be impacting other API operations where there is not response from the service, but the SDK is trying to unmarshal one. Such as Amazon CloudWatch's PutMetricData.

@jasdel jasdel self-assigned this Jan 15, 2021
@Chandrian
Copy link

Getting the exact same issue with sqs.DeleteMessage call, here's some logs:

SDK 2021/01/15 21:30:36 DEBUG request failed with unretryable error https response error StatusCode: 200, RequestID: xxx, deserialization failed, failed to decode response body, DeleteMessageResult node not found

But it looks like the sqs message was properly deleted.

jasdel added a commit to jasdel/smithy-go that referenced this issue Jan 15, 2021
Updates the SDK's generated serializers and deserializers to skip unmodeled
input and output shapes for operations.

This issue caused generated deserializers to attempt to deserialize
operation responses that were not modeled, resulting in an error.
Whereas the SDK should of ignored the response if one was present for
operations without a modeled output.

Related to aws/aws-sdk-go-v2#1047
jasdel added a commit to jasdel/aws-sdk-go-v2 that referenced this issue Jan 15, 2021
jasdel added a commit to aws/smithy-go that referenced this issue Jan 16, 2021
Updates the SDK's generated serializers and deserializers to skip unmodeled
input and output shapes for operations.

This issue caused generated deserializers to attempt to deserialize
operation responses that were not modeled, resulting in an error.
Whereas the SDK should of ignored the response if one was present for
operations without a modeled output.

Related to aws/aws-sdk-go-v2#1047
Fixes #262

#### Input
Unmodeled Input shape serializer functions are not generated.

This update changes API protocol operation serializers for HTTP binding protocols to skip serialization of the request document if the operation's input was not modeled.

This change is **not** applied to HTTP RPC protocol serializations. This is due to the AwsQuery protocol requiring some protocol specific elements to always be serialized regardless if an input is modeled or not.

#### Output
Unmodeled output shape serializer functions are not generated.

This update changes all API protocol operation deserializers to discard the response body if the operation's output was not modeled.
jasdel added a commit that referenced this issue Jan 16, 2021
…output (#1050)

Updates the SDK's generate serializers and deserializers for operations without modeled input and output types. This fixes #1047 where the SDK was attempting to deserialize a response from a service for an operation that had no modeled output. The SDK should of ignored the response instead of trying to deserialize it.

This update will not attempt to serialize inputs for operations without modeled inputs, and will discard responses from services of operations with unmodeled outputs.

Related to aws/smithy-go#261
Fixes #1047
@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

@jasdel
Copy link
Contributor

jasdel commented Jan 16, 2021

Thanks for reporting these issues, We've merged in the fix for this bug and will be included in the SDK's next published release.

In the meantime you can use the HEAD of the SDK's repo using go get commands to the git hash, e18d7141fc06 You'll need to do this for all SDK modules that you are using in your application.

# Update SDK's core modules:
go get github.com/aws/smithy-go@fd031a74deeb
go get github.com/aws/aws-sdk-go-v2@e18d7141fc06
go get github.com/aws/aws-sdk-go-v2/service/sts@e18d7141fc06
go get github.com/aws/aws-sdk-go-v2/feature/ec2/imds@e18d7141fc06
go get github.com/aws/aws-sdk-go-v2/credentials@e18d7141fc06
go get github.com/aws/aws-sdk-go-v2/config@e18d7141fc06

# Update SDK API clients your application uses.
go get github.com/aws/aws-sdk-go-v2/service/s3@e18d7141fc06
go get github.com/aws/aws-sdk-go-v2/service/sqs@e18d7141fc06

If you get errors about module not available try running the above commands with the GOSUMDB environment variable disabled.

export GOSUMDB=off

@jasdel
Copy link
Contributor

jasdel commented Jan 19, 2021

Thanks for reporting these issues. The bug has been fixed, and is included in the SDK's v1.0.0 release. The SDK is now release for General Availability (GA), and ready for use in production applications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants