You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm new to GraphQL in general, but I think in the original PR #323 the AppSyncResolverEvent was based on AWS Amplify, so instead of reading parentTypeName, we are reading typeName.
It confused me that the code is consistent (in some ways) with AWS AppSync Context info:
"""The name of the parent type for the field that is currently being resolved."""
returnself.info.parent_type_name
This has the side-effect that when setting up an AppSync resolved in AWS like the following, it does not work out of the box and you have to pass typeName to make it work:
import{util}from'@aws-appsync/utils';/** * Sends a request to a Lambda function. Passes all information about the request from the `info` object. * @param {import('@aws-appsync/utils').Context} ctx the context * @returns {import('@aws-appsync/utils').LambdaRequest} the request */exportfunctionrequest(ctx){return{operation: 'Invoke',payload: {fieldName: ctx.info.fieldName,parentTypeName: ctx.info.parentTypeName,typeName: ctx.info.parentTypeName,// Extra field which is exactly the same as the one abovearguments: {},// Extra fieldvariables: ctx.info.variables,selectionSetList: ctx.info.selectionSetList,selectionSetGraphQL: ctx.info.selectionSetGraphQL,},};}/** * Process a Lambda function response * @param {import('@aws-appsync/utils').Context} ctx the context * @returns {*} the Lambda function response */exportfunctionresponse(ctx){const{ result, error }=ctx;if(error){util.error(error.message,error.type,result);}returnresult;}
Which area does this relate to?
Event Source Data Classes
Solution
I'm not sure if it was the intention and it should stay the same, but I think we can improve this in different ways:
If the old approach is not desired, we can just deprecate it and mention parent_type_name should be used
If the old approach is still valid, we can try to read info from parentTypeName after typeName is checked. This way it is consistent with the AWS Resolver context here and with the Amplify structure
Hi @aminalaee! Thanks for reporting this! I'll check on Monday, but I think we have a bug here.
The reason I'll check out this is because we use some of these fields in our AppSync Event Handler utility and I don't know if we have this bug there as well, so I want to test everything together.
Thanks, And about your point of this usage, I think it's kind of the same that in other places type_name is used where we mean parent_type_name. To me seems like this was only to follow AWS Amplify and seems like that is not consistent with AWS Resolver Context.
Why is this needed?
I'm new to GraphQL in general, but I think in the original PR #323 the
AppSyncResolverEvent
was based on AWS Amplify, so instead of readingparentTypeName
, we are readingtypeName
.It confused me that the code is consistent (in some ways) with AWS AppSync Context info:
But we are assigning variables in a way they are not clear:
powertools-lambda-python/aws_lambda_powertools/utilities/data_classes/appsync_resolver_event.py
Line 161 in a3f3359
And we define different property names for reading the
parentTypeName
:powertools-lambda-python/aws_lambda_powertools/utilities/data_classes/appsync_resolver_event.py
Lines 121 to 124 in a3f3359
powertools-lambda-python/aws_lambda_powertools/utilities/data_classes/appsync_resolver_event.py
Lines 165 to 168 in a3f3359
This has the side-effect that when setting up an AppSync resolved in AWS like the following, it does not work out of the box and you have to pass
typeName
to make it work:Which area does this relate to?
Event Source Data Classes
Solution
I'm not sure if it was the intention and it should stay the same, but I think we can improve this in different ways:
parent_type_name
should be usedinfo
fromparentTypeName
aftertypeName
is checked. This way it is consistent with the AWS Resolver context here and with the Amplify structureI can prepare a PR if the suggestion makes sense.
Acknowledgment
The text was updated successfully, but these errors were encountered: