Internal server error for animated GIFs

[gianpaolom]

I have installed the module and it works properly so far. I have recently noticed that however I get an internal error for animated GIFs.
Any clue about this?

[ofhouse]

Ah, I see we currently have no tests for animated GIF (only for animated webp).
Need to take a look, thanks for the hint!

[ofhouse]

Tested the internal middleware against an animated gif and seems to work fine: milliHQ/pixel#9

Are you able to share the image in question?

[gianpaolom]

Hi! This is an example of image causing the error:

Here the link:
https://cdn.player-state.com/_next/image/?url=https%3A%2F%2Fplayerstate-files-prod-20210629151257820000000001.s3.eu-west-2.amazonaws.com%2Fsubmission-media%2F5d1e2736-295a-44e8-b87e-46c4013c3da6.gif&w=1920&q=75

[ofhouse]

Thanks, will take a look over the weekend!

[ofhouse]

Unfortunately it seems the image hit the max payload size for AWS Lambda of 6mb.
Since the image has ~8mb it cannot be sent back from Lambda as Response.

The limit cannot be increased by AWS so the only option here would be to replace the image with a smaller one (<6mb).
Don't know for sure if we could implement a workaround here, so that the original image is served when the limit is hit.

[gianpaolom]

@ofhouse Thank you for looking into the issue!
I will have the developers to set a constraint on the upload size for GIFs

Re the workaround, if you ever happen to figure something out, maybe just bump reference this thread so I get a heads up!

Thank you again for your work! :)

[gianpaolom]

Hello @ofhouse! I just had a thought, but not sure if it could apply, as I am not aware about how the image resizing is handled.
However, to try to workaround that payload limit, couldn't it work if you read the image from s3 as a stream, you pipe into sharp, and the write again as a stream to s3?

[ofhouse]

Hi @gianpaolom,
yes the basic idea is to use a direct connection from CloudFront to S3 to avoid the limits from Lambda & API Gateway.

The best solution currently would be to introduce a new S3 bucket as short-term cache (e.g. save the processed images there for 30 days, then expire the objects, to save costs).
To process the images I would recommend to add a S3 Object Lambda to the S3 bucket.
So every response from S3 through CloudFront triggers an invocation.
If the image already exists, do not modify the object.
When the image does not exists, start the processing and save the result back to S3.

As stated in the linked blog post:

Finally, I use the new WriteGetObjectResponse API to send the result of the transformation back to S3 Object Lambda. In this way, the transformed object can be much larger than the maximum size of the response returned by a Lambda function.

So this should also work for payload sizes that exceed the lambda limit.