Amplify-cli: Provide a verbose option to see reason for a failure

[shawnlauzon]

Is your feature request related to a problem? Please describe.
The CLI sometimes displays an error and does not give enough information why. For example, just the phrase "Access Denied"

➜  directory-on-tap git:(master) ✗ amplify push --verbose
| Category | Resource name | Operation | Provider plugin   |
| -------- | ------------- | --------- | ----------------- |
| Auth     | dotauthdev    | Delete    | awscloudformation |
? Are you sure you want to continue? true
✖ An error occurred when pushing the resources to the cloud

Access Denied

or

✖ An error occurred when pushing the resources to the cloud

Your socket connection to the server was not read from or written to within the timeout period. Idle connections will be closed.

Describe the solution you'd like
I would like an option --verbose and -v which would display the operations which the CLI is performing on the server. With that information, I can diagnose what is the problem and then make changes to the CloudFormation document or User Policy.

Describe alternatives you've considered
I've tried to guess what is wrong, but it's a frustrating (and unsuccessful in my case) way of understanding what is going wrong.

[kaustavghosh06]

@shawnlauzon We've improved logging of errors in the latest version of the CLI with a clear description of the resource and the reason for failure. Please feel free to check it out and let me know if you think we can further improve upon the same. Closing this issue and feel free to re-open if you've suggestions for making this feature better.

[kevinyea]

@kaustavghosh06 Please can you explain what's been done because I'm using "latest" and don't see any improvement , e.g. a way to find out how to solve:

There is virtually nothing useful in this error message and, like so many, left now to spend hours performing digital autopsies.

Thanks

[rajeshrthl]

I've got this same issue. Is there no way to see verbose error message when running amplify commands? Adding a flag like --verbose would be greatly helpful when debugging issues.

[fsommers]

I wonder if there's any progress on this. Right now, I'm stuck on trying to add an aurora cluster as a GraphQL data source. The command line just hangs. I would like to have a some tracing / verbose output so see just where things get stuck. Is that possible to obtain from the amplify cli?

[flyandi]

Is there any progress here.. this is not useful:

[groundswel]

Please .. this is really important! I just changed my schema.graphql file to add couple of connections and subsequent amplify push gives a terse error message which is not enough!

✖ An error occurred when pushing the resources to the cloud

Attempting to edit the key schema of the VacationTable table in the Vacation stack.
An error occurred during the push operation: Attempting to edit the key schema of the VacationTable table in the Vacation stack.

[groundswel]

Ok I dont know if I should call this as Amplify's hidden feature 😒

When I ran amplify api push instead of amplify push I got a much better error message:

✖ An error occurred when pushing the resources to the cloud

Attempting to edit the key schema of the VacationTable table in the Vacation stack.
There was an error pushing the API resource
Attempting to edit the key schema of the VacationTable table in the Vacation stack.
Cause: Adding a primary @key directive to an existing @model.
How to fix: Remove the @key directive or provide a name e.g @key(name: "ByStatus", fields: ["status"]).
~

[groundswel]

OK this should be fixed. Any self respecting CLI should have a --verbose option IMHO and this is the standard practice. Right now I am trying to recreate my APIs and amplify cli push is just sitting there and not going forward. I have no clue whatsoever on what is going on. @kaustavghosh06 ^^^

[kaustavghosh06]

@groundswel We provide all the Cloudformation stack events when deploying your backend. So, be default the information we provide is verbose.
Sometimes resources like Elasticsearch and Cloudfront distribution take more than 15-20 mins to provision - which might result in this behavior. Are you provisioning one of these resources (for the first time)?
Also, can you paste your terminal outputs, which would help us understand better what's going on?

[groundswel]

@kaustavghosh06 the issue in my case was due to network issue Amplify CLI could not connect to one of the endpoints (api) and ultimately it error out with a socket error. However it took almost 20 mins to time out and show the socket error. If there was a verbose option (like usually CLI commands have) that would have shown in greater detail what the CLI was doing and I think it would be easier to troubleshoot.

[phishy]

As @groundswel pointed out, the error is different depending on how you call the CLI. When I received Attempting to edit the key schema of the VacationTable table in the Vacation stack, I literally had no idea what to do next. Perhaps this could be referenced in the docs for key

[claym]

Yeah, I'm trying to remove an environment that's mangled and here's what amplify is telling me:

? Are you sure you want to continue? (This would delete all the environments of the project from the cloud and wipe out all the local amplify resource files) Yes
- Deleting resources from the cloud. This may take a few minutes...
Deleting env:dev
| Deleting resources from the cloud. This may take a few minutes...(node:23164) UnhandledPromiseRejectionWarning: NoSuchKey: The specified key does not exist.
    at Request.extractError (C:\Users\clay\AppData\Roaming\nvm\v12.2.0\node_modules\@aws-amplify\cli\node_modules\aws-sdk\lib\services\s3.js:816:35)
    at Request.callListeners (C:\Users\clay\AppData\Roaming\nvm\v12.2.0\node_modules\@aws-amplify\cli\node_modules\aws-sdk\lib\sequential_executor.js:106:20) 
    at Request.emit (C:\Users\clay\AppData\Roaming\nvm\v12.2.0\node_modules\@aws-amplify\cli\node_modules\aws-sdk\lib\sequential_executor.js:78:10)
    at Request.emit (C:\Users\clay\AppData\Roaming\nvm\v12.2.0\node_modules\@aws-amplify\cli\node_modules\aws-sdk\lib\request.js:683:14)
    at Request.transition (C:\Users\clay\AppData\Roaming\nvm\v12.2.0\node_modules\@aws-amplify\cli\node_modules\aws-sdk\lib\request.js:22:10)
    at AcceptorStateMachine.runTo (C:\Users\clay\AppData\Roaming\nvm\v12.2.0\node_modules\@aws-amplify\cli\node_modules\aws-sdk\lib\state_machine.js:14:12)   
    at C:\Users\clay\AppData\Roaming\nvm\v12.2.0\node_modules\@aws-amplify\cli\node_modules\aws-sdk\lib\state_machine.js:26:10
    at Request.<anonymous> (C:\Users\clay\AppData\Roaming\nvm\v12.2.0\node_modules\@aws-amplify\cli\node_modules\aws-sdk\lib\request.js:38:9)
    at Request.<anonymous> (C:\Users\clay\AppData\Roaming\nvm\v12.2.0\node_modules\@aws-amplify\cli\node_modules\aws-sdk\lib\request.js:685:12)
    at Request.callListeners (C:\Users\clay\AppData\Roaming\nvm\v12.2.0\node_modules\@aws-amplify\cli\node_modules\aws-sdk\lib\sequential_executor.js:116:18) 
(node:23164) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:23164) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
- Deleting resources from the cloud. This may take a few minutes...

And then it just spins. This is not helpful :(

[esteban-uo]

+1 to this.

Adding some sort of verbosity mechanism is not only about cloudformation but also any other kind of execution during codegen for instance. This helps us as developers to have more hints on what could be wrong without bothering you first.

IMHO, tools like amplify should aim with high priority decoupling any dependency from users as much as possible to develop fast.

i.e, I had an error recently like:

Cannot read property 'fields' of undefined
An error occurred during the push operation: Cannot read property 'fields' of undefined

by writing an example from GraphQL as:

# error
type Post @auth(rules: [{ allow: owner }]) @model {
  id: ID!
  title: String!
}

That can become quite frustrating for new users.

Thanks!

[mudassir0909]

_posting if someone else runs into the same issue_

I was having the error

Syntax Error: Expected Name, found )
An error occured during the push operation: Syntax Error: Expected Name, found )

And my schema was

type Foo {
  bar: String!
}

type Mutation
{
 performOperationFoo(): Foo @function(name:"somelambdaname")
  @aws_iam
  @aws_cognito_user_pools
}

The solution was to change performOperationFoo(): to performOperationFoo:

The final result looked like the following, which compiled successfully

type Mutation
{
 performOperationFoo: Foo @function(name:"somelambdaname")
  @aws_iam
  @aws_cognito_user_pools
}

[vitalbone]

Could really use a -verbose flag right about now.

It's hard to know what to debug when the only response is Error updating cloudformation stack...

➜ amplify push --yes
✔ All resources copied.
✔ Successfully pulled backend environment dev from the cloud.

Current Environment: dev

| Category      | Resource name                    | Operation | Provider plugin   |
| ------------- | -------------------------------- | --------- | ----------------- |
| Video         | myprojectvideostream             | Update    | awscloudformation |
| Auth          | myprojectapi5e11                 | No Change | awscloudformation |
| Auth          | userPoolGroups                   | No Change | awscloudformation |
| Api           | myprojectapi                     | No Change | awscloudformation |
| Function      | submit.                          | No Change | awscloudformation |
⠏ Updating resources in the cloud. This may take a few minutes...Error updating cloudformation stack
✔ All resources are updated in the cloud