Thumbnail endpoint returns 500 if the upstream image URL 404s
sarayourfriend opened this issue · 0 comments
sarayourfriend commented
Description
I was looking through production logs to see where some 500 errors were coming from and I found a handful of logs that look like this:
| Field | Value |
|---|---|
@ingestionTime |
1659625225674 |
@log |
140733703834:/prod/api/nginx |
@logStream |
i-05a7072edd44e97d9 |
@timestamp |
1659625221900 |
| body_bytes_sent | 66 |
| host_header | api.openverse.engineering |
| http_referrer | https://search.openverse.engineering/ |
| http_user_agent | Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.134 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) |
| http_x_forwarded_for | [redacted] |
| remote_addr | [redacted] |
| request | GET /v1/images/81954166-168e-41a6-bff5-eb966cb940ec/thumb/ HTTP/1.1 |
| request_time | 1.175 |
| status | 500 |
| time_local | 04/Aug/2022:15:00:21 +0000 |
| upstream_response_time | 1.175 |
Indeed, if you visit https://api.openverse.engineering/v1/images/81954166-168e-41a6-bff5-eb966cb940ec/thumb/ you will get a 500 back with a message saying that the upstream request resulted in a 404. I think these should just 404 all the way, instead of resulting in a 500.
I wonder if these should also be marked as dead links? It should already be anyway because the upstream url 404s and this is how we detect dead links during the search request, but clearly some still get through 🤔
Reproduction
- Visit https://api.openverse.engineering/v1/images/81954166-168e-41a6-bff5-eb966cb940ec/thumb/
- See the 500 response code with the 404 body details.
Resolution
- 🙋 I would be interested in resolving this bug.