Open mgarabedian opened 3 years ago
josefaidt
commented
2 years ago Hey @mgarabedian :wave: thanks for raising this! I'm starting to take a look at this, however in the mean time would you mind providing a small example showing how the resolvers are set up?
josefaidt
commented
2 years ago Hey @mgarabedian just wanted to follow-up on this one to see if you are able to provide a small example showcasing how the resolvers are set up?
mgarabedian
commented
2 years ago Sure. I have DatasourceInvokeLambdaUser as an example. If you create another one also called DatasourceInvokeLambdaUserSettings, and had the pipeline function reference it, DatasourceInvokeLambdaUser would be called.
Resolver:
"DeleteUserResolver": {
"Type": "AWS::AppSync::Resolver",
"Properties": {
"ApiId": {
"Ref": "GetAttGraphQLAPIApiId"
},
"FieldName": "deleteUser",
"TypeName": "Mutation",
"Kind": "PIPELINE",
"PipelineConfig": {
"Functions": [
{
"Fn::GetAtt": [
"RandomPipelineFunction",
"FunctionId"
]
},
{
"Fn::GetAtt": [
"InvokeLambdaUser",
"FunctionId"
]
}
]
},
"RequestMappingTemplateS3Location": {
"Fn::Sub": [
"s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/resolvers/${ResolverFileName}",
{
"S3DeploymentBucket": {
"Ref": "S3DeploymentBucket"
},
"S3DeploymentRootKey": {
"Ref": "S3DeploymentRootKey"
},
"ResolverFileName": {
"Fn::Join": [
".",
[
"Mutation",
"deleteUser",
"req",
"vtl"
]
]
}
}
]
},
"ResponseMappingTemplateS3Location": {
"Fn::Sub": [
"s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/resolvers/${ResolverFileName}",
{
"S3DeploymentBucket": {
"Ref": "S3DeploymentBucket"
},
"S3DeploymentRootKey": {
"Ref": "S3DeploymentRootKey"
},
"ResolverFileName": {
"Fn::Join": [
".",
[
"Mutation",
"deleteUser",
"res",
"vtl"
]
]
}
}
]
}
}
},Pipeline FunctionConfiguration:
"InvokeLambdaUser": {
"Type": "AWS::AppSync::FunctionConfiguration",
"Properties": {
"ApiId": {
"Ref": "AppSyncApiId"
},
"Name": "InvokeLambdaUser",
"DataSourceName": "InvokeLambdaUser",
"FunctionVersion": "2018-05-29",
"RequestMappingTemplateS3Location": {
"Fn::Sub": [
"s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/pipelineFunctions/${ResolverFileName}",
{
"S3DeploymentBucket": {
"Ref": "S3DeploymentBucket"
},
"S3DeploymentRootKey": {
"Ref": "S3DeploymentRootKey"
},
"ResolverFileName": {
"Fn::Join": [
".",
[
"InvokeLambdaUser",
"req",
"vtl"
]
]
}
}
]
},
"ResponseMappingTemplateS3Location": {
"Fn::Sub": [
"s3://${S3DeploymentBucket}/${S3DeploymentRootKey}/pipelineFunctions/${ResolverFileName}",
{
"S3DeploymentBucket": {
"Ref": "S3DeploymentBucket"
},
"S3DeploymentRootKey": {
"Ref": "S3DeploymentRootKey"
},
"ResolverFileName": {
"Fn::Join": [
".",
[
"InvokeLambdaUser",
"res",
"vtl"
]
]
}
}
]
}
},
"DependsOn": "DatasourceInvokeLambdaUser"
},Lambda as Datasource:
"DatasourceInvokeLambdaUser": {
"Type": "AWS::AppSync::DataSource",
"Properties": {
"ApiId": {
"Ref": "AppSyncApiId"
},
"Name": "DatasourceInvokeLambdaUser",
"Type": "AWS_LAMBDA",
"ServiceRoleArn": {
"Fn::GetAtt": [
"UserLambdaRole",
"Arn"
]
},
"LambdaConfig": {
"LambdaFunctionArn": {
"Fn::If": [
"HasEnvironmentParameter",
{
"Fn::Sub": [
"arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:LambdaUser-${env}",
{
"env": {
"Ref": "env"
}
}
]
},
{
"Fn::Sub": [
"arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:LambdaUser",
{}
]
}
]
}
}
},
"DependsOn": "UserLambdaRole"
},Hey @mgarabedian :wave: apologies for the delay! I was able to successfully reproduce this behavior.
Where our InvokeLambdaTodo*.req.vtl templates are:
{
"version": "2017-02-28",
"operation": "Invoke",
"payload": {
"field": "createTodo",
"arguments": $utils.toJson($context.arguments)
}
}And InvokeLambdaTodo*.res.vtl
$util.toJson($ctx.prev.result)Finally, with our two Lambda functions todo and todosettings we can add a console.log statement:
exports.handler = async (event) => {
console.log('hello from todo')
const payload = {
id: '1234',
name: 'John Doe',
}
const response = {
statusCode: 200,
body: JSON.stringify(payload),
}
return response
}And upon running the mock server with amplify mock api and attempting to run mutation createTodoSettings..., we can see the console.log statement from the todo lambda in the console.
Marking as a bug š
Before opening, please confirm:
How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
14.17.3
Amplify CLI Version
6.3.1
What operating system are you using?
Mac
Amplify Categories
api
Amplify Commands
Not applicable
Describe the bug
While using custom transformers and pipeline functions in a mock environment, I came across a bug. It seems as though mock is picking up the wrong datasource if the name prefixes are the same. See the following example datasource names:
If my custom mutation uses a pipeline function that calls DatasourceGetUserSettings, DatasourceGetUser is executed instead.
Expected behavior
The exact datasource with the name provided should be found and executed.
Reproduction steps
See above in description. Removing the 'e' from User, and changing the name to DatasourceGetUsrSettings, everything works again as expected.
GraphQL schema(s)
No response
Log output
Additional information
No response