Corrupted image breaks entire image menu

[Pixelguymm]

To Reproduce

Unsure at the moment. Images have gotten corrupted at seemingly random times, it's unclear whether this is a bug with Apostrophe or something on our end. Mind you, this has nothing to do with the image file being missing or corrupted, it seems like the image is missing any reference to image files at all.

Expected behavior

When an image is corrupted, don't load it, or show that the image is broken.

Describe the bug

The corrupted image fails to load, causing all other images and the "Drop new media here" box not to appear.
The images do exist however. Clicking the checkbox in the top left reveals all images on the right side of the menu, including the broken image. Archiving this image will fix the bug for the live images, but will in turn break the archive.

In the browser console I recall seeing something along the lines of Cannot read properties of null (reading '_urls').

Details

Server Operating System: A Docker image based on node:lts-alpine3.15. The MongoDB database runs in a separate container.
This has only occured in production so far.

Screenshot:
This is a recreation of what the image menu would look like with a corrupted image.

[boutell]

My first thought here is that perhaps you haven't addressed persistence for your uploads. Each time you restart your container, your images will be gone like the rest of any writes made to the "disk" inside the container during a previous run, unless you have either mapped public/uploads to a persistent Docker volume, or configured uploadfs to store them somewhere else, like S3.

Note that if you are trying to scale to multiple servers then uploadfs is not optional, as the volume approach only makes sense on a single server.

[boutell]

Our cookbook here covers using a volume:

https://docs.apostrophecms.org/cookbook/using-docker.html

And here's a cookbook on using S3 via uploadfs:

https://docs.apostrophecms.org/cookbook/using-s3-storage.html

[Pixelguymm]

There is a volume in place, so I don't think that's the issue. It is worth noting that the images currently available were copied over from my local test build, alongside their respective images files.

We have found out that the corruption occurs upon selecting an image from the list of existing images. The selected image will become corrupted. Removing all existing images and importing them again would probably be the way to go for us at the moment.

In any case, my point still stands that this exception should be handled in some way, rather than blocking the whole image menu.

[boutell]

Apostrophe doesn't modify existing images when you select them. We haven't seen anything like that, and there is no logic that would modify the existing files. The closest I can think of is the logic to crop an image, and that only adds some additional files.

However... this is Docker. And Docker is great for creating reproducible test cases.

So what I suggest is that you create a reproducible test case so that we have a means to debug it.

I don't doubt that there is an issue here, we just can't do much with it until we have a means of reproducing it.

[Pixelguymm]

Unfortunately I don't know how to reproduce this one, and I can't make the affected project public either. I might try to reproduce it at some point but it could be a while.

Also, forgive me for mixing up terminologies, but when I said "corrupted" I didn't mean the image files, those are fine as far as I know. I presume it's the image's database record that loses some properties, causing _urls to be inaccessible. Accounting for this possible null reference should at least fix the frontend.

[boutell]

OK. I'm going to close this ticket for housekeeping since there is no path to reproducing the issue, but feel free to reopen if you find a way.

[Pixelguymm]

Hey! I just so happened to stumble across the cause of the bug. When transfering data from my local instance to the server, we didn't include the attachments table. Only upon saving an image with a missing attachment, would it become broken. Why it doesn't occur earlier is unclear to me.

I think the original intention of this report was missed. I figured the cause would be something on our end, but in case someone makes the same mistake in the future, it would be best if the null reference was handled in some way rather than breaking the UI.

[boutell]

Now that we know how to reproduce it, I think it makes sense to reopen this ticket because I agree Apostrophe could be more informative in this situation. It's not a common case - database integrity is something our code does have to mostly expect - but it could be an area for a community contribution, which could be as simple as printing at least a server console warning if an attachment is not found.