Getting a "The specified key does not exist" error even though the object is present in S3

[lithium-oxide]

Hi,

I have just deployed v4.0 of this solution. After I upload an image to the source S3 bucket I get the following message, even though the object exists and is public (I can access it directly via an S3 URL):

{"status":500,"code":"NoSuchKey","message":"The specified key does not exist."}

Here's an example:

• https://d3g99zcrnlow87.cloudfront.net/subfolder/4simon.jpg (500)
• https://image-handler-testing.s3.amazonaws.com/subfolder/4simon.jpg (200)

Oddly, when I upload an image to the root of the bucket, I can retrieve the image via the API/distribution without any issue:

• https://d3g99zcrnlow87.cloudfront.net/simoncoveney.jpg (200)
• https://image-handler-testing.s3.amazonaws.com/simoncoveney.jpg (200)

What's weirder again is that if I then re-upload that second example to a sub-folder, after first uploading it to the root, it can be retrieved via the API/distribution:

• https://d3g99zcrnlow87.cloudfront.net/subfolder/simoncoveney.jpg
• https://image-handler-testing.s3.amazonaws.com/subfolder/simoncoveney.jpg

We can see here that the 500 response is not coming from CloudFront, but from the API (or something further along the process): https://wc9am3chn1.execute-api.us-east-1.amazonaws.com/image/subfolder/4simon.jpg

Can anyone give any insight into what's going on?

Conor

[soupy1976]

What you are seeing is most likely this issue with the the Thumbor mapping:
#112

The reason it works when you re-upload it to a subfolder is because it always looks in the root, no matter what path you give it, so if it still exists in the root then it will work.

[rpong]

Implemented a fix for this as follows:

https://github.com/awslabs/serverless-image-handler/pull/130/files#diff-08e877f927a879fa2fe8faa4d6b1a1de

You may use the above for the specific issue you are facing, but if you're willing to re-pack the node_modules of your function, you might use the PR where the fix above is a part of.

the PR is at -> #130

node_modules re-pack might be necessary because this PR will use a more recent version of Sharp.

The said PR contains several other fixes such as /fit-in/ behavior, strange "{}" return for images captured with samsung cams, improper resizing if 'x' is part of filename etc. Use at your own risk.

[techmag]

I've just deployed the version 4 (as I too have just my sites break...) and I can't get it to work either.

I just deployed the "front end demo site" or whatever that is called and I have confirmed that the demo program CANNOT handle folders whatsoever.

If you have a folder in the root and you have an image within that then it is impossible to get it to load in the front end demo.

If you place the image itself in the root then it works no problem.

I've tried all manor of quotes, escapes and encodings and yet nothing I've tried works.

I tried the resultant URLs as well just in case it was a display issue with the front end demo however none of them worked either.

Since you can not MOVE objects in S3 (you can with custom code...) most people would have to download everything and re-upload to the root.

Do we have a fix for the folder issue on the horizon?

FYI: When you specify a file in the root it is WITHOUT the LEADING slash.

GOOD: my-file.jpg

BAD: /my-file.jpg

NEVER GOING TO HAPPEN: my-folder/my-file.jpg

[rpong]

I've just deployed the version 4 (as I too have just my sites break...) and I can't get it to work either.

I just deployed the "front end demo site" or whatever that is called and I have confirmed that the demo program CANNOT handle folders whatsoever.

If you have a folder in the root and you have an image within that then it is impossible to get it to load in the front end demo.

If you place the image itself in the root then it works no problem.

I've tried all manor of quotes, escapes and encodings and yet nothing I've tried works.

I tried the resultant URLs as well just in case it was a display issue with the front end demo however none of them worked either.

Since you can not MOVE objects in S3 (you can with custom code...) most people would have to download everything and re-upload to the root.

Do we have a fix for the folder issue on the horizon?

FYI: When you specify a file in the root it is WITHOUT the LEADING slash.

GOOD: my-file.jpg

BAD: /my-file.jpg

NEVER GOING TO HAPPEN: my-folder/my-file.jpg

see my reply above yours, the only fix right now is for you to go to your Lambda function, Actions -> Export Function. Unzip the package, modify the code, re-zip and re-upload the function package with your changes. The changes needed are outlined in the my comment above, you may also apply the whole PR which fixes several other issues.

[andyfurniss4]

Any updates on when this will be properly fixed? This is still an issue for newly created stacks.

[adrianosmateus]

Any fix? Im facing this same problem

[rpong]

@andyfurniss4 , @adrianosmateus , we have fixed this in our fork, we have a pre-bundled export you can use readily:

https://github.com/innovationlove/serverless-image-handler/releases/tag/4.0.1-ilove

Use at your own risk.

[beomseoklee]

We have updated our solution, and I believe your issue has been fixed. If you still see the issue with the latest version (v4.2), please feel free to reopen the issue.

You can refer to the recent changes here

[sraviteja07]

we have similar issue happening with a spring batch job. but when the batch job is re-run the job is successful. I am not sure if there is any latency between write and read operations when this is happening .

Can anyone explain the cause?

[Himanshu824]

we also have same issue like this . we implemented aws-sdk in our angular application and we get the object file sometimes it gives error no specified key found even the key is proper . when i checked in the requested url we have %20 text instead of ' ' space . any solution to resolve this

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[sbiastoch]

I have the same issue, but not permanently. Sometimes the image is found and resized correctly, sometimes I get a 404 for the same image but with different parameters. It seems not really deterministic, so it is hard to give steps to reproduce :-/

[dougtoppin]

@sbiastoch Can you check the Lambda log in CloudWatch to see if anything is being logged that might indicate what is happening?
A key not found error return may log more information that might be helpful.
Checking the request image key in the CloudWatch log entry would also be used to see if there is something different in the key when an image not found is returned.

[dougtoppin]

We have not been able to duplicate this report and are closing it.

If it occurs again, please re-open the issue and provide details for

• version
• region
• relevant CloudWatch log entries for errors and request details that might impact request processing
• if possible, provide a request that produces the issue