Resize photo configuration option to not store failures

nickconfer · April 21, 2025, 7:09pm

We have recently upgraded our CMS setup and have moved to the resizer service you implemented. One of the issues we’ve noticed having a closer look on everything is how assets work when they fail.

If my understanding is correct, a resized asset is stored (a network drive in our case) and does not need to be resized again for the same settings as long as the download is able to read the file.

The resizer when run attempts to resize the original photo, but when it fails serves the original file while adding it as the resized file for future use.

Our problem is two fold.

Occasionally download fails, causing the asset to be resized again. We are uncertain of why this is happening, its rather infrequent, but this issue is not greatly concerning if resizer works.
When resizer works everything is great. When it fails (could be due to lack of resources from a lot of requests at once, or another issue), it saves the original photo as a resized photo. As we encourage our staff to upload large photos to be future proof, one bad resized photo can more than 2x the size of our page. To put this in perspective our homepage with resized photos is about 1.5MB of image assets. A single photo not resized is 2.8MB. So one bad image can almost 3x the homepage. A lot of times when there is a failure (and pod needs to self heal), multiple photos on the same page will fail.

Would it be possible to add a configuration option that…

Logs when a resize fails and original image is served
Does not store the failed resized image in file cache so the next request can attempt a resize again.

I don’t know for certain, but our assumption is the system is in current form because as there is not full control over assets added to Squidex, having this enabled by default could be very costly, causing the same asset to try to resize on every request that may never resize properly. On our end, I believe all our assets should resize, or we could get with our small crew to use a different file, so serving the full image temporarily and then caching the correct resized photo will help give our users the best experience. Adding the log would help us monitor for a file that keeps failing on resize to fix.

Would greatly appreciate your assistance here, or further knowledge into system. We plan to have our asset storage grow significantly soon and I’m concerned these failures will greatly impact our page load and performance.

Sebastian · April 21, 2025, 10:30pm

The resize server already logs errors:

github.com

Squidex/libs/blob/main/assets/Squidex.Assets.ResizeService/ImageResizer.cs#L97


      
                  await assetThumbnailGenerator.CreateThumbnailAsync(
                      tempStream,
                      context.Request.ContentType ?? "image/png",
                      context.Response.Body, options,
                      context.RequestAborted);
              }
              catch (Exception ex)
              {
                  var log = context.RequestServices.GetRequiredService<ILogger<ImageResizer>>();
          
                  log.LogError(ex, "Failed to resize image.");
          
                  context.Response.StatusCode = 400;
              }
          }
          
          private static async Task ReadToTempStreamAsync(HttpContext context, Stream tempStream)
          {
              await context.Request.Body.CopyToAsync(tempStream, context.RequestAborted);
          
              tempStream.Position = 0;

There is also a “force” parameter which bypasses the cache. I think it makes more sense to keep it as is and then repair the failed images manually.

nickconfer · April 22, 2025, 2:51pm

Thanks for the info on log.

Will be a second before I can follow-up, we reverted our change yesterday and are pushing out again Friday. Want to confirm we are seeing the log when failures pop up again. Not sure if that log would include the info we’d need to know the exact image or not since it would be in exception details currently.

In terms of the force push, that could fix something that is broken, but it would require us to manually process it each time. We were hoping to have a setting to just stop the full-size photo from being added as a resized photo to begin with so it would auto correct itself on the next run. Otherwise, I doubt we will be able to keep up with these manually.

Sebastian · April 22, 2025, 7:25pm

It is a balance. The setting also had disadvantages. I would actually try to solve your hosting problem first, because I do not see a single error regarding that in the cloud.

nickconfer · April 22, 2025, 8:54pm

Sounds good. We’ll try to fix on our end first.

Sam asked me if you could give us any insights on the memory allocation you have for these pods?

Sebastian · April 23, 2025, 7:31am

I have not configured anything particular. I just wanted to move it to cloud run anyway. If you have a serverless deployment option I would choose that.