AppId mismatch failure in preview build of backend used across apps
Amplify CLI Version
latest (12.13.0)
Overview
We have several apps, assuming their appIds are A and B.
App A is not actively used anymore, but we still uses the backend resources associated to AppId A. Therefore, even though we interact with B when we configure preview builds, our code's team-provider-info.json has appId = A.
With #13954, it started to fails with AppId mismatch which checks the appId from meta and appId from commandline.
Questions
Considering it's possible to use Amplify backends across apps, I feel it's possible that AppId of the app on console does not match with appId retrieved from metafiles (which is for backend, IIUC).
- When backend is used across apps, is it WAI that this error is thrown or does it come from our misconfiguration? Any idea on where to fix?
- I assume removing appId from commandline can be a workaround but I'm not sure where we configure that. Do you have any pointer?
Trace
2024-10-10T14:01:17.716Z [INFO]: [0mAmplify AppID found: <APPID OF APP B>. Amplify App name is: <APP NAME OF APP B>[0m
2024-10-10T14:01:17.770Z [INFO]: [0mBackend environment stg found in Amplify Console app: <APP NAME OF APP B>[0m
2024-10-10T14:01:19.921Z [WARNING]: - Fetching updates to backend environment:XXXs from the cloud.
2024-10-10T14:01:21.503Z [WARNING]: - Building resource api/XXXX
...
2024-10-10T14:01:24.592Z [WARNING]: ✔ Successfully pulled backend environment XXX from the cloud.
2024-10-10T14:01:25.190Z [INFO]: ✅
2024-10-10T14:01:27.372Z [INFO]: 🛑 Amplify appId mismatch.
2024-10-10T14:01:27.372Z [INFO]: Resolution: You are currently working in the amplify project with Id <APPID OF APP A>
Learn more at: https://docs.amplify.aws/cli/project/troubleshooting/
The same thing is happening to me. Is there any update?
Hey folks, thank you for reaching. Could you provide us some additional on the reproduction steps? Are you running into this when associating an existing backend app to a frontend app using the console branch edit button? https://docs.aws.amazon.com/amplify/latest/userguide/reuse-backends.html#reuse-backends-edit-existing
The problem is related to the preview generation. They were working fine and suddenly started throwing an error.
In my case, I have two apps, and App A uses the backend from App B. For some reason, the PR previews for App A stopped working due to the error. 🛑 Amplify appId mismatch.
Here is the error:
Hi @ykethan, thank you for checking. The situation is exactly what first comment and @felixpro describes. Just to clarify, it is as follows:
Overview
We have two apps: A and B.
We use app B to trigger preview deploy of frontend for Github branch.
However, our team-provider-info.json has AmplifyAppId = A because we use the backend associated to the app A.
It has been working fine until recently, but suddenly deploy preview started to fail with AppId mismatch. It corresponds with the release of 12.13.0
So repro steps would be:
- Create initial app A
- Create second app B and Follow https://docs.aws.amazon.com/amplify/latest/userguide/reuse-backends.html#reuse-backends-create-connect to connect to backend of app A
- Set up deploy preview of app B
- Trigger deploy preview and it fails
short-term workaround
Going to app > Hosting > Build Configuration > Build Image Configuration and pin the Amplify CLI version as 12.12.6
Why workaround is not desirable
We need to pin the CLI version and never be able to catch up with the latest
@felixpro @Ruci0094 thank you for the information. I was able to reproduce the issue by adding the amplify-meta.json file to my git repository.
Could you confirm if the repository currently does have the amplify-meta.json file present under the amplify/backend?
to note the amplify-meta.json should be .gitignored, refer to the amplify-meta and .gitignore documentation providing this information.
Could you confirm if the repository currently does have the amplify-meta.json file present under the amplify/backend?
No, amplify-meta.json is .gitignored so we don't see that file in the repo. I assume it is generated in the build of deploy preview, maybe?
Same as Ruci0094, amplify-meta is ignored in my repo.
thank you for the confirmation on the gitignore. On a quick check with Amplify team, they suggest verifying your version control system as while the file maybe gitignored for any changes the file may have been pushed/committed to the repository previously. tried reprod
Additionally, if the file is indeed not present version control system would be happy in diving into the issue over a call. I am available on discord and my handle is ykethan
Thank you, I double confirmed that there is no meta file in the repo. I sent you a friend request on discord. (I'm not familiar with discord so let me know if I do something weird). I'm on JST (+09:00) and available on Oct.18 16:30 ~ 18:30 PDT so if you happen to have time, please ping me. We can discuss other schedule further on discord or I'm happy to share whatever information you need asynchronously if it's hard to find an overlapping slot.
Hey @ykethan I also added you on Discord. I confirm there is not meta file in the repo.
Joining in here, same issue. Any resolution yet or in the near future? Thanks
hey folks, wanted to provide an update. if the repository currently does not contain a amplify-meta.json, could you try adding AMPLIFY_BACKEND_PULL_ONLY as true as the environment variables on the frontend app referring to a backend hosted on a different app in the Amplify console. Do let us know if this mitigates the issue.
hey folks, wanted to provide an update. if the repository currently does not contain a
amplify-meta.json, could you try addingAMPLIFY_BACKEND_PULL_ONLYas true as the environment variables on the frontend app referring to a backend hosted on a different app in the Amplify console. Do let us know if this mitigates the issue.
Adding that environment variable in the amplify console, and then setting the build settings back to the latest CLI did seem to work. Does adding that variable have any other potential negative side effects that I should be aware of, or does that basically let it work how it was working in version 12.12.6? I should still be able to deploy back-end updates through this app despite setting that variable right?
Thanks for the quick reply!
hey folks, wanted to provide an update. if the repository currently does not contain a
amplify-meta.json, could you try addingAMPLIFY_BACKEND_PULL_ONLYas true as the environment variables on the frontend app referring to a backend hosted on a different app in the Amplify console. Do let us know if this mitigates the issue.
Yeah so actually I'm not sure this environment variable is a viable option, it actually does not update the back-end at all when adding this variable. As the name implies, it's skipping over updating the backend on the deployment. When using the amplify cli build 12.12.6 workaround as stated above, it still does update the backend code. That is what we need, not to skip the backend updates.
In our case the reason we ended up in this situation is because the amplify app was started out as a manually deployed app, and there is no good way to switch it over to an automated CI/CD deployed app. So we had to create another "amplify app" in the console just to connect it to our repository to our first amplify app, and that is how we are in this situation. There never has been a good way to migrate over to CI/CD when the app starts out as manually deployed. I think many people are in that boat because when doing development you just assume lets do it manually when starting out but then realize later you got stuck.
As @121940kz pointed out, it occurs in a branch even when we need to deploy (update) backend so I think AMPLIFY_BACKEND_PULL_ONLY cannot be a workaround.
We are running into the same exact issue and have provided build logs in AWS support case ID: 173089142200287
Like others, we have temporarily pinned the Amplify CLI Version to 12.12.6 as to avoid getting bit by recent validation changes introduced with 12.13.0. Similar to what was pointed out by others, we too are in a scenario where we have a deprecated application (let's call it app "B") that is associated with a backend that's being used by an active application (let's call it app "A"). And thus, when we try to build app "A", we get the mismatch appId (of app "B").
For anybody else who is afflicted with this issue, providing a little update from our case that we cut with AWS:
... They have picked the issue and are currently investigating a workaround that will allow developers to opt out of this behaviour. I will let you know once this workaround has been implemented. Following it up closely with the internal service team.
Will provide updates as I receive them.
Thank you @itsmemattchung for sharing your updates! That is helpful. Hope there will be an opt-out option soon.
So continuing to push the internal ticket and there is a fix (see below) that just got merged in. Essentially, once it's (i.e. 12.13.x) rolled out, you will be able to set an external environment variable (below) to bypass this failing check (for those of who have shared backends):
AMPLIFY_SKIP_APP_ID_MISMATCH_CHECK = TRUE
https://github.com/aws-amplify/amplify-cli/pull/14013
Although I'm unsure on the internal AWS service's team deployment, I'm hoping to get an ETA in the next day or so!
Amplify CLI version 12.13.1 has been released providing this fix. To upgrade amplify CLI run amplify upgrade locally and set to latest on Amplify console build settings.
Could you add the AMPLIFY_SKIP_APP_ID_MISMATCH_CHECK as environment variable and let us know if this mitigates the issue.
I am confirming that the issue is now fixed in 12.13.1. Last night, I went ahead with the following two changes:
- Reverted pinning 12.12.6 and resetting the AWS Amplify CLI version to "latest"
- Set environment variable (i.e.
AMPLIFY_SKIP_APP_ID_MISMATCH_CHECK=true)
Deployment now succeeds!
Same here! Thank you everyone involved for your support :)
This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.