Problem/Motivation
Cases to cover:
- Metadata is unable to be fetched due to a transient error, such as a 5XX response.
- Metadata is unable to be fetched, but it requires administrator intervention, such as when API credentials are invalid.
- A metadata error is thrown during a user-interface action, like saving a media entity, and the entity save should be aborted or metadata queued for later.
- A metadata error is thrown while processing the queue. If it's a transient error, the item should be re-queued to the bottom of the queue. If it's a "permanent" error, do we delete the queue item?
- A thumbnail download fails, and we fall back to the default thumbnail. The queue should attempt to get the thumbnail again later.
- No error occurred, the metadata is empty (this is the one case currently handled by core).
Steps to reproduce
Proposed resolution
Remaining tasks
Depends on #2878119: Whether queued or not, update the media thumbnail and metadata before beginning the entity save database transaction.
Postponed on #2983456: Expose triggering update of media metadata + thumbnail to end users
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2983728-review-not-to-test.patch | 3.89 KB | vijaycs85 |
Comments
Comment #3
vijaycs85We could try
a) throw an exception for cases that just need to be simple logging.
b) Dispatch an event for the cases that require additional actions - e.g. adding to queue.
Here is a (sample) patch to handle thumbnail update failure. This patch applied on top of #2878119-101: Whether queued or not, update the media thumbnail and metadata before beginning the entity save database transaction and just for review purpose.
Comment #4
deviantintegral commentedI like the idea of dispatching an event for error handling. However, is there ever a reason why multiple subscribers would want to respond to the same event? It seems like there'd be close to a one-to-one mapping between media source plugins and subscriber implementations.
To me, what's missing currently is good default handling for common error conditions, especially related to network or HTTP errors. For example, if a thumbnail update times out, or 503s, it would be reasonable to transparently requeue the thumbnail. I think the same holds for metadata updates too. It feels a bit fragile to require contrib developers to duplicate this in most modules providing a media source.
So how about something like:
Thoughts?
Comment #5
deviantintegral commentedComment #13
quietone commentedThe issue this is postponed has been closed as won't fix. The last comments in that issue refer to continuing in #2983456: Expose triggering update of media metadata + thumbnail to end users so I am changing this issue to be postponed on that issue.