Amplify does not recognize function created in a separate git branch

[cfbo]

Which Category is your question related to? Function

Amplify CLI Version 5.3.1

What AWS Services are you utilizing? Api, function, storage, auth,

Provide additional details e.g. code snippets

Help needed with an amplify push issue, please! :pray:

• A colleague and I were working on two different envs (envA and envB), in separate git branches (br1 and br2).
• We both added (different) functions in each env (let's called function funX and funY). We both performed an amplify push in each one env and did git pushes while progressing work.
• At some point we wanted to merge our developments because we know there would have been issues in amplify
• Basically I have merged his branch in my branch, locally. There were git conflicts, in particular in backend-config.json. Having both added functions, the conflict was in the function section of course.
• We manually merged the conflicts, very carefully, i.e. I am 100% that file is syntactically correct and both functions are correctly declared.
• I then run an amplify push, which worked successfully.
• However the amplify status does not list my colleague's function (funB)... of course it was available in the backend-config.json and the related folder under amplify/function was there. Therefore my env (envA) did not build that lambda in the cloud.. and of course this causes errors (the lambda is invoked by the react frontend but it's not there)

I don't know how to get out from that situation! What is the correct procedure to handle such scenario?? Should I have used an amplify command to merge envB in envA? Shouldn't be enough the git merge and then a push?

Some more attempts on that:

• Given that the function was missing in my env, I then tried to an amplify add function to manually create the missing function (funY)... I noticed that after this, funY was added to my env (envA) in the team-provider-info.json. Of course the folder for funY was already in my amplify folder and amplify kept that.. it did just override some files (e.g. adding basic permissions for that function and removing the permission my colleague had assigned to it).. so I then inspected the diff in git and made sure to (very carefully) discard some of the changes made by the amplify add the original settings from my colleague. However performing another amplify push at this point, I got an error...

[cfbo]

I found a solution, but I still would like someone to help me understand if this is okay and also tell me what are best practices to avoid finding ourselves in this kind of situation.

When I merged the branch with all the changes (including the result of the merge) into a test branch which has an automated build associated to it, it worked, i.e. it created the missing function (funB).

Is there any reason why the amplify cloud build worked and the local amplify push via CLI didn't?

[josefaidt]

Hey @cfbo :wave: apologies for the delay, but thank you for taking the time to file this and include detailed reproduction steps! I was able to reproduce by creating a similar setup with two separate environments, in two separate local directories, both connected to separate git branches corresponding to their envs. In each branch I created a function, pushed to Amplify, then pushed to git. In the "main" branch & env I ran a git merge to merge in the changes performed in the other branch, and received conflicts as you mentioned.

These conflicts are described as the following:

• conflicts to add each environment and categories into team-provider-info.json
• conflicts to add each function to backend-config.json

Since neither Amplify env existed in the other, this is where those conflicts arise. Though unfortunately I experienced the same issue where now the new function does not show in the list of resources for the current env, I was able to run amplify env checkout <current-environment-name>, which initialized this category in the current environment. Running this command populates the resource metadata in amplify-meta.json which is used to gather resource information when running commands like amplify status. This approach is similar to how we enable custom resources.

Marking this as a feature request to the team to improve the multi-environment flow when merging content from a separate branch with new, alike resources.

[cfbo]

@josefaidt Thanks for coming back to me and taking the time to reproduce the scenario.

If understood correctly, a workaround is the following: when merging branch 2 into branch 1 and while amplify is on envA, after resolving the git conflicts we should also run an amplify env checkout envB, is that correct?

I will add something that is sort of related to merging into new branches/env, but should probably go in a separate ticket Whenever I do the merge, if the new function added in the branch being merges is using the SSM to store secrets, upon amplify push a block of comments will be added again, even if one exists. This keeps going if one has quite a few envs. The current approach I am using is to discard these changes (when they are just a duplicate of a comment that is already there) I would think this is an issue. Any feedback on this?

[josefaidt]

If understood correctly, a workaround is the following: when merging branch 2 into branch 1 and while amplify is on envA, after resolving the git conflicts we should also run an amplify env checkout envB, is that correct?

Apologies for the confusion, after resolving git conflicts we want to run checkout on the current env. In this case while we are on envA we'll want to run amplify env checkout envA

if the new function added in the branch being merges is using the SSM to store secrets, upon amplify push a block of comments will be added again, even if one exists

Yes I've noticed this recently as well, may you open a separate issue? I'll add my notes to that issue as well, as I've noticed it will add that block when updating a function if it has secrets enabled.