Method Optional about aws-lambda-events HOT 9 CLOSED

That makes sense, sorry for breaking that use case. I have also seeing that you can get empty strings, which I fixed by using GET as default: https://github.com/LegNeato/aws-lambda-events/blob/master/aws_lambda_events/src/custom_serde.rs#L234

I really wish they had a schema. Making it optional, and the change in the Go library make sense to me.

from aws-lambda-events.

@calavera looks like we might have dropped the optional bit on translation.

from aws-lambda-events.

Looks like a regression from a90dd07#diff-e8389648fe67543e9be7cfa1a7d104432051756fd08fa4c5c32bd0c498a97583

from aws-lambda-events.

Hm, actually this looks wrong on the Go side:

https://github.com/aws/aws-lambda-go/blob/master/events/apigw.go#L9

from aws-lambda-events.

Before we had a blanket Go string to Rust Option<String> conversion, as Go will coerce a null string to "", as mentioned in the README (go's default behavior is so lame). Because this is no longer a string after #29, we don't do the blanket conversion and thus hit this bug.

While I put up a PR for this case on the go side (aws/aws-lambda-go#350, will take time) we might want to have it always be Option<Method> on the Rust side.

Thoughts?

from aws-lambda-events.

(this isn't really handled well by the C# bindings either: https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.APIGatewayEvents/APIGatewayProxyRequest.cs, "This field is only set for REST API requests.")

from aws-lambda-events.

@jatsrt do you use the same lambda function to receive HTTP events and WS events? or only WS events? The Go library makes a distinction about the kind of APIGateway events you receive by using two different types. The code in this library is still broken either way, but it might make more sense to modify the WS event type, and not the HTTP event type.

Apparently, different language bindings implement this in different ways, so I'm not sure at all about what's the best action to take.

from aws-lambda-events.

Im my use cases they are always separate.

from aws-lambda-events.

Still not optional in the request context, so it causes an error still

from aws-lambda-events.