Updates to Fargate/Container-Based API Services Not Reflected After Purported Successful Redeployment

[medelman17]

Describe the bug

When I update the source for a given Fargate/Container-based API service, the CLI fails to repackage the distribution asset. Instead, the CLI appears to upload the existing latest-build.zip asset that was generated upon initial deployment. As a result, none of the changes made to the service are thereafter present in production.

Building and pushing the image to ECR locally solves the issue. See also additional context below.

Amplify CLI Version
4.44.0

To Reproduce

1. Create a fully-managed Fargate/Container-based API using the Amplify CLI.
2. Deploy said service via amplify push.
3. Observe that the initial deployment was successful.
4. Make any change to the contents of the amplify/backend/api/<FARGATE_API_NAME>/src directory.
5. Re-run amplify push.
6. Note that the CLI appropriately determines that an update to the service is needed.
7. Once the redeployment succeeds, observe that the above change is not present in the deployed service.

Expected behavior
Once the CLI determines that an update is needed, the CLI repackages the distribution asset, and, thereafter, uploads the newly repackaged asset to S3.

Desktop (please complete the following information):

• OS: Mac
• Node Version. 15.8.0

Additional context
Notably, all signifiers point to a successful redeployment—with the notable exception described above—making the issue quite insidious and likely to frustrate users. Indeed, the asset object on S3 shows that it has been recently modified, reflecting that the CLI successfully uploaded something. CodePipeline is successfully triggered; a build is executed and a new version of the image is pushed to ECR. Thereafter, Fargate successfully swaps out the existing container for one based on the newly generated image. The CLI finishes and everything looks copacetic.

@manueliglesias and I confirmed that the source stored on S3 does not reflect the anticipated changes. Further, the modified date for the latest-build.zip in the service directory locally appears to reflect the time that the service was initially deployed.

Potentially related to #6359, although, in this case, the CLI appropriately recognizes that an update is needed and purports to move forward as expected.

[osnodegeoffrey]

+1 for this. Really annoying.
I also noted that, if switching computer, it will complain that the dist/latest-build.zip isn't found. I'm not sure if it is supposed to create/fetch it at some point or amplify pull should get it but neither are working.

Downloading the zip from S3 makes it pass the error but doesn't update anyways.

[fr3shn3ss]

+1 for being a annoying bug

Here is a workaround I found.

1. Edit your code
2. Zip it and replace it with latest-build.zip in this path:
   amplify\backend\api\conatainerXXXXXX\dist
3. amplify api push

[mattfysh]

amplify-cli/packages/amplify-nodejs-function-runtime-provider/src/utils/legacyPackage.ts

Line 7 in eb9257e

if (!request.lastPackageTimeStamp || request.lastBuildTimeStamp > request.lastPackageTimeStamp!) {

I believe this is the bug. This if condition should evaluate to true when the ZIP file should be created, but in my case:

    lastPackageTimeStamp: 2021-05-13T04:33:39.562Z,
    lastBuildTimeStamp: undefined,

So the if evaluates to false, and the zip file is not created

[cjihrig]

@mattfysh a fix landed for this in a27a033, and it should be available in the next release.

[github-actions]

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels for those types of questions.