Amplify-cli: How do you debug resolvers?

[YikSanChan]

* Which Category is your question related to? *
API

* What AWS Services are you utilizing? *
AppSync

* Provide additional details e.g. code snippets *
Curious about how do you debug your resolvers. It is nice that resolvers are generated for us. However, there are cases (that directives @auth, @connection, etc haven't covered) when we have to modify resolvers. Unfortunately, I don't know how to debug resolver.

I tried to use CloudWatch to log (just as people print in Python/Java/...). E.g., in request template mapping, I add $ctx.identity hoping to print it to CloudWatch. No luck. Yes, $ctx.identity is not logged by CloudWatch :(

$ctx.identity
{
  "version": "2017-02-28",
  "operation": "GetItem",
  "key": {
      "id": $util.dynamodb.toDynamoDBJson($ctx.args.id)
  }
}

This will work with mock data, but mock data doesn't help, in many cases. I also asked on AppSync forum, no luck.

According to AWS customer support, the AppSync team mentioned that they will consider the following as a feature request:

1. Log $ctx.identity object in Cloudwatch
2. Ability to 'print'/'log' in VTL

I am curious how do you debug? Or you simply do everything correctly? 🤣The question is also asked https://github.com/awslabs/aws-mobile-appsync-sdk-js/issues/14 and https://github.com/awslabs/aws-mobile-appsync-sdk-js/issues/15, but I don't think it is answered.

[bmilesp]

Yes a print log function would be ideal!

[mikeparisstuff]

Thanks for the suggestion. This request has been accounted for and will be investigated. I'm going to close this issue because it is being tracked in a different system and will be implemented outside of this repository.

[vparpoil]

Hi @mikeparisstuff Can you share an update about this log/print ability ? Thank you very much !

[sebastienfi]

This is a real bummer.

[sopranolinist]

This is a hack, but you can get $ctx.identity to show up in the logs if you switch to a pipeline resolver and put the following line in the Before Mapping Template section:

$util.toJson($ctx.identity)

If you have logging enabled (with field resolver level set to All) then the value of this variable will appear in the very first Request Mapping log line as the value of context.prev.result.

If you're not using a pipeline resolver you can always convert to one, do your debugging, then copy/paste your code into a new resolver once you're done.

[Nxtra]

This is a hack, but you can get $ctx.identity to show up in the logs if you switch to a pipeline resolver and put the following line in the Before Mapping Template section:

$util.toJson($ctx.identity)

If you have logging enabled (with field resolver level set to All) then the value of this variable will appear in the very first Request Mapping log line as the value of context.prev.result.

If you're not using a pipeline resolver you can always convert to one, do your debugging, then copy/paste your code into a new resolver once you're done.

Indeed, it's a workaround but it works for me. Thanks.