Image processing - moving to a job (asynchronous)

[nimmolo]

The question here is whether it's desirable to offload image upload processing to a Solid Queue job.

When images are uploaded to MO (say for Create Obs), they go through a second step where they are "processed". They get resized to several smaller dimensions, and then everything gets uploaded to the image server.

This "process" happens synchronously. The server is doing that until it's done.

• The advantage of doing it that way is that you have the server's full attention. If there's an error, you can get it from the operation in progress.
• The disadvantage is that it is a blocking operation, according to Jason. It's done on the production server, and it's probably affecting performance.

By making it a "Job", the server can do it when it's not busy, and adjust for its own resource budget. This seems like it would be a performance improvement for the server overall. Jason seems to feel that it's probably "the right way to do it". He raised some good points though:

It would mean that we have to handle errors a bit differently in both the UI and the API, because jobs do not return info. They can handle errors, but they do not return messages. The errors have to result in some other Ruby action: a database update, an email, etc.

I spoke with Jason about a pattern proposed by AI. According to this, we'd add an upload_status column to Image, and set it to something like pending when the process starts. On success it would be set to success; on error it would be set to the error message.

Currently in "Create Obs" we don't handle error reporting in the UI. If someone does something like rename a ".pages" file as a ".jpg" and tries to upload it as an image, the UI just seems to hang. The console shows a 500 error, but the front end user doesn't receive it on the page. That could definitely be improved.

The main difference with doing it as a Job is we'd need to use something like websockets to "broadcast" any image processing errors to the user — maybe in their flash_messages div, or maybe in a notifications inbox — or send them an email. The UI wouldn't be waiting for the images to process, and the user would be free to go on and do other things, so we'd need to build a way to get them error messages.

With the API, the consideration is similar, but we can't use websockets. The client would need to poll the image.upload_status to find out if the upload worked, or we'd need to email them.

[mo-nathan]

Now that I read this, I agree. The way I've generally dealt with job errors in the past (and the way I do it with PDF generator) is to have a page users can go to where they can see the status. In this case, I would think we'd put a link somewhere on the observation page that shows up when associated images are "processing" or in the "error" state. They can click on the link to get more details. We cannot assume that users will keep a web page open to MO after they do their upload. This would also address the API (read Mobile) case.

[ChrisNeefus]

Has something like this been implemented? The MushroomLog app I wrote has stopped being able to upload images to mo. It would be good to know where the problem lies.

[nimmolo]

I worked on it and eventually realized it's impossible to make image uploads a background job without re-doing a bunch of the validation steps — the images need to be uploaded on the backend before the observation is created. I scrapped this idea.

[nimmolo]

Thanks. Ok, i'll see if i can make progress on it.

(On the separate Vips question - in case you're curious to read about it, this is a Rails discussion leading up to switching their default from ImageMagick.)

https://discuss.rubyonrails.org/t/make-vips-the-recommended-default-variant-processor-for-active-storage/78368/