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

dynamodbattribute.Decoder panics on decoding map with custom-typed key #2868

Closed
DiabuFR opened this issue Oct 1, 2019 · 1 comment · Fixed by #2870
Closed

dynamodbattribute.Decoder panics on decoding map with custom-typed key #2868

DiabuFR opened this issue Oct 1, 2019 · 1 comment · Fixed by #2870
Assignees
Labels
bug This issue is a bug.

Comments

@DiabuFR
Copy link

DiabuFR commented Oct 1, 2019

Please fill out the sections below to help us address your issue.

Version of AWS SDK for Go?

1.25.3

Version of Go (go version)?

go version go1.11.2 windows/amd64

What issue did you see?

dynamodbattribute.Decoder panics when unmarshaling to a Map with a custom key type:

panic: reflect.Value.SetMapIndex: value of type string is not assignable to type dynamodbattribute.Key
goroutine 20 [running]:
testing.tRunner.func1(0xc0001aa100)
	C:/Go/src/testing/testing.go:792 +0x38e
panic(0x74e500, 0xc0000435c0)
	C:/Go/src/runtime/panic.go:513 +0x1c7
reflect.Value.assignTo(0x74e500, 0xc0000435a0, 0x98, 0x7ca720, 0x19, 0x74db80, 0x0, 0x0, 0x0, 0x0)
	C:/Go/src/reflect/value.go:2269 +0x453
reflect.Value.SetMapIndex(0x75f4c0, 0xc000076088, 0x195, 0x74e500, 0xc0000435a0, 0x98, 0x74e500, 0xc0000435b0, 0x198)
	C:/Go/src/reflect/value.go:1526 +0xb5
github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute.(*Decoder).decodeMap(0xc000187da0, 0xc000187d70, 0x75f4c0, 0xc000076088, 0x195, 0x0, 0x75f4c0)
	E:/GoWS/src/github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute/decode.go:497 +0x463
github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute.(*Decoder).decode(0xc000187da0, 0xc000047860, 0x7419a0, 0xc000076088, 0x16, 0x0, 0x0, 0x0, 0x77d020, 0xc000187d01)
	E:/GoWS/src/github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute/decode.go:186 +0x2e5
github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute.(*Decoder).Decode(0xc000187da0, 0xc000047860, 0x7419a0, 0xc000076088, 0x0, 0x0, 0x0, 0x7ad160, 0x7a8301)
	E:/GoWS/src/github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute/decode.go:151 +0x1c3
github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute.UnmarshalMap(0xc000187d70, 0x7419a0, 0xc000076088, 0x8, 0xc000198978)
	E:/GoWS/src/github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute/decode.go:88 +0xa6
...

Steps to reproduce

func TestDecodeMapWithCustomKeyType(t *testing.T) {
	type Key string

	aKey := "aKey"
	aValue := "aValue"

	decodedMap := map[Key]string{}

	attrs := map[string]*dynamodb.AttributeValue{
		aKey: {S: aws.String(aValue)},
	}
	if err := UnmarshalMap(attrs, &decodedMap); err != nil {
		t.Fatal(err)
	}
	if val, ok := decodedMap[Key(aKey)]; !ok {
		t.Fatal("expected key not found in decoded map")
	} else if val != aValue {
		t.Fatal("unexpected value for key in decoded map")
	}
}

Interpretation of what's happening

In decodeMap (decode.go:492), the underlying type of key (reflect.Value) is always a string because we create it from k (string):

for k, av := range avMap {
	key := reflect.ValueOf(k) // <= Here
	elem := reflect.New(v.Type().Elem()).Elem()
	if err := d.decode(av, elem, tag{}); err != nil {
		return err
	}
	v.SetMapIndex(key, elem)
}

Proposed fix

Instead, we should create key based on the type of the map v and set its string value:

for k, av := range avMap {
	key := reflect.New(v.Type().Key()).Elem()
	key.SetString(k)
	elem := reflect.New(v.Type().Elem()).Elem()
	if err := d.decode(av, elem, tag{}); err != nil {
		return err
	}
	v.SetMapIndex(key, elem)
}
@skmcgrail
Copy link
Member

Thanks for reporting this bug @qProust. I have created a pull request to incorporate the outlined change. PR: #2870

@skmcgrail skmcgrail self-assigned this Oct 2, 2019
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.

2 participants