Companion issue for https://github.com/aws/aws-dax-go/issues/18
v1.25.9
go version)?go1.12.9 darwin/amd64
Nil-dereference panics from attempts to access nil retryer function r.MaxRetries() of request object here: https://github.com/aws/aws-sdk-go/blob/master/aws/request/request.go#L557
This a result of passing a nil retryer to NewDaxRequest in aws-dax-go as described in https://github.com/aws/aws-dax-go/issues/18.
Use dax go client to read from a dynamo table and force a server error from Dynamo. For us, we set read capacity to 1 read unit and started getting throttled event errors from Dynamo.
A potential solution is to ensure all accesses of r.MaxRetries() only happen if aws.BoolValue(r.Retryable) is true:
https://github.com/aws/aws-sdk-go/blob/master/aws/request/request.go#L557
We also filed against the dax go project as a fix in both places would make dep management much easier for consumers of both libraries.
Hi @CMLivingston, thanks for reaching out to us about this. Unfortunately I haven't been able to reproduce this using the sample code for aws/aws-dax-go modified to send GetItem requests instead of PutItem - I'm able to elicit ProvisionedThroughputExceededException errors without the client panicking on a nil dereference. Can you provide a code sample that exhibits this behavior so we can better understand how you're running into this?
In order to reproduce it you have to do the following:
cfg := dax.
cfg.HostPorts = []string{endpoint}
cfg.Region = region
client := dax.New(cfg)
in := &dynamodb.GetItemInput{
TableName: aws.String(table),
Key: key,
}
r, _ := client.GetItemRequest(in)
r.Send()
so the key point here is to use Request.Send method, which we actually don't use in our examples
Thanks for letting us know about this issue. I've merged in PR #2934 which patches the ability of the SDK to more cleanly handle a nil Retryer value. This change will be included in our next tagged release.
Thanks!
Most helpful comment
In order to reproduce it you have to do the following:
so the key point here is to use
Request.Sendmethod, which we actually don't use in our examples