Amplify-cli: Switching environments with different profiles prevents Appsync from updating.

[tncbbthositg]

Describe the bug
I have an application with two environments. A beta and a production environment. Each uses a different AWS PROFILE and they're connected to two different accounts. The stacks deploy correctly in the two associate accounts.

When I switched back to beta from release with amplify env checkout beta and try to use amplify push, I get an error updating appsync.

```UPDATE_IN_PROGRESS GraphQLSchema AWS::AppSync::GraphQLSchema Wed Mar 27 2019 23:03:31 GMT-0400 (EDT)
UPDATE_IN_PROGRESS GraphQLAPIKey AWS::AppSync::ApiKey Wed Mar 27 2019 23:03:31 GMT-0400 (EDT)
⠴ Updating resources in the cloud. This may take a few minutes...

UPDATE_FAILED GraphQLSchema AWS::AppSync::GraphQLSchema Wed Mar 27 2019 23:03:33 GMT-0400 (EDT) Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: YDH3325463535230; S3 Extended Request ID: EHykv8n1J1Bwc2sct0Pm5z+SStVQjCWNPXtOBGY4pdmTF2SDekotZeAyLu2NuiN0RiEhNHpkbtE=)
⠇ Updating resources in the cloud. This may take a few minutes...

UPDATE_COMPLETE GraphQLAPIKey AWS::AppSync::ApiKey Wed Mar 27 2019 23:03:33 GMT-0400 (EDT)
UPDATE_ROLLBACK_IN_PROGRESS myapp-20190327202612-api-32IAEYXBDYPDX AWS::CloudFormation::Stack Wed Mar 27 2019 23:03:34 GMT-0400 (EDT) The following resource(s) failed to update: [GraphQLSchema].
```

To Reproduce
Steps to reproduce the behavior:

1. Init a new amplify application and create a default environment with an AWS profile in one account
2. amplify push
3. Create a second environment with a different AWS profile in a second account
4. amplify push
5. amplify checkout the first environment
6. amplify push
7. Stack is unable to update due to access denied error

Expected behavior
I expect to be able to switch back and forth between environments and deploy updates to each of them.

Desktop (please complete the following information):

• OS X

Additional context
Amplify-CLI version 1.1.7

[UnleashedMind]

I need more information to investigate this further, could you describe what you've added to your GraphQL API?

[dbramwell]

I've just run into this myself. The issue seems to boil down to the S3 properties inside amplify/backend/api/<whatever>/build/parameters.json, they seem to be used whether the API has changed or not.

• Create an environment, env1, with AWS profile in account1
• Add an api and a function, and push the env. This creates said file with S3DeploymentBucket and S3DeploymentRootKey.
• Create a new environment, env2, with AWS profile in account2
• Push. This modifies said file with new S3DeploymentBucket and S3DeploymentRootKey for new env and aws account.
• Checkout env1, make changes to the function (not the api)
• Push. Api is unchanged and so said file is not modified, S3DeploymentBucket and S3DeploymentRootKey remain correct for env2 (incorrect for the env we are pushing), however at some point the process tries to access this bucket and key, giving the access denied error.

I guess a fix could be replacing that parameters file with the one that's inside #current-cloud-backend when changing envs?

[et304383]

This is likely related to the error I get that the "specified key does not exist" when switching env and trying to push. It's like the upload to S3 of the schema.graphql isn't taking place except during add of the API resource (or on a schema definition change).

Amplify REALLY needs to be rewritten to do all of this compilation at DEPLOYMENT time, not at time of resource being added/configured.

Look at what serverless does, and do that. The approach you've taken does not work.

All in all, the multi-env support in Amplify really needs some work.

[pdkeating-globo]

I guess a fix could be replacing that parameters file with the one that's inside #current-cloud-backend when changing envs?

@dbramwell Just to confirm, this approach did work for me. Modifying the S3DeploymentRootKey and the S3DeploymentBucket in the amplify/backend/api/<whatever>/build/parameters.json file to the respective values in each AWS account allowed me to use amplify push for the different environments.

That being said, there should be a fix to this, perhaps adding the S3DeploymentRootKey and S3DeploymentBucket to the team-provider-info.json file for each env would solve the problem.

[bartvollebregt]

I have the same problem but when I change the S3DeploymentRootKey in the parameters.json and run amplify push amplify overwrites the S3DeploymentRootKey before pushing...

[kaustavghosh06]

@bartvollebregt Yes, the S3DeploymentRootKey is based on a hash generated based on the file contents of the resolvers and it would change if there are any changes to the schmea or the resolvers.

@dbramwell We've a PR for this issue in #2003

[SwaySway]

Closing the PR #2003 as it has been released in the latest version of the CLI (3.15.0)