Deleting Cloudinary Assets

Options
dalusel
dalusel Member Posts: 14
edited May 15 in Developer APIs

Hi,

I am using this API Cloudinary::Api.delete_resources([public_id_1, public_id_2], { all: true, resource_type: 'video' })

I am planning to delete the original asset and other derived transformations EXCEPT one of the transformations (basically thumbnail) of the original asset.

Is that possible? If so, please suggest me how to achieve that.

Tagged:

Comments

  • Cloudinary Team
    Cloudinary Team Administrator, Cloudinary Staff Posts: 129 admin
    Options

    Hi Dalusel,

    Thanks for reaching out.

    So when you delete the original asset, all the derived get deleted as well and it is not possible to just keep one derived.

    However, what you can do is use the URL for the derived asset you want to keep to overwrite the original asset by specifying the public_id during upload. Also make sure to pass overwrite=true and invalidate=true as well to make the asset gets overwritten and invalidated as per https://cloudinary.com/documentation/image_upload_api_reference.

    Then after that you can delete all the derived assets via Admin API by specifying keep_original=true so original asset isn't deleted.

    Please let me know if you need anything else.

    Kind Regards,
    Thomas

    Developer Support Engineer
    Customer Success team
    Cloudinary UK


    Helpful Links For You
    💬 Share questions, connect with other users in our Cloudinary Community forums and Discord server!
    🧑‍🎓 Join our Cloudinary Academy for free courses, workshops and other educational resources.
    📄 Read our documentation for in-depth details on Cloudinary product features and capabilities
    📰 Check out the Cloudinary blog for the latest company news and insights

  • dalusel
    dalusel Member Posts: 14
    Options

    Thank you for your prompt response.

  • dalusel
    dalusel Member Posts: 14
    edited May 15
    Options

    Hi,

    When the original asset is deleted, all associated derived assets are also deleted as expected. Upon accessing the original URL of those deleted assets, they are restored to Cloudinary from backup (S3). However, an issue arises when generating transformations on-the-fly for videos.

    When attempting to access derived assets after the original asset is restored, I observe that the transformation occurs on-the-fly and creates a derived asset. However, if I try to access the derived assets before the original asset is restored, I receive a 404 error (as expected). Strangely, even after the original asset is restored, retrying to access the derived assets still results in a 404 error.

    We utilize the Cloudinary API Cloudinary::Utils.cloudinary_url(public_id, transformation: transformation) for generating URLs. It seems that Cloudinary may have cached the request that resulted in a 404 error (when attempting to access derived assets before the original asset was restored) and does not retry to generate the transformation even after the original assets are restored.

    To address this issue, we need a way to force the generation of derived assets with transformations, invalidating the cache if necessary. Alternatively, can you suggest a method that reliably generates derived assets from the original asset everytime if it is unavailable?

    By the way, the video size is less than 100MB.

  • dalusel
    dalusel Member Posts: 14
    Options

    Hi,

    When the original asset is deleted, all associated derived assets are also deleted as expected. Upon accessing the original URL of those deleted assets, they are restored to Cloudinary from backup (S3). However, an issue arises when generating transformations on-the-fly for videos.

    When attempting to access derived assets after the original asset is restored, I observe that the transformation occurs on-the-fly and creates a derived asset. However, if I try to access the derived assets before the original asset is restored, I receive a 404 error (as expected). Strangely, even after the original asset is restored, retrying to access the derived assets still results in a 404 error.

    We utilize the Cloudinary API Cloudinary::Utils.cloudinary_url(public_id, transformation: transformation) for generating URLs. It seems that Cloudinary may have cached the request that resulted in a 404 error (when attempting to access derived assets before the original asset was restored) and does not retry to generate the transformation even after the original assets are restored.

    To address this issue, can you suggest a way to force the generation of derived assets with transformations, invalidating the cache if necessary? Alternatively, can we request a method that reliably generates derived assets from the original asset every time if it is unavailable?

    By the way, the size of the video is less than 100 MB.

  • Cloudinary Team
    Cloudinary Team Administrator, Cloudinary Staff Posts: 129 admin
    Options

    Hi Darusel,

    Thanks for getting back.

    The reason why that particular URL is resulting in a 404 is that the URL (for the derived/transformed image) was accessed prior to the original image being uploaded/available, and the 404 errors were cached.

    Cloudinary caches 4xx errors first for 1 minute, and each subsequent non-cached request for the same URL that results in the error doubles the expiry time up until it reaches 24 hours maximum. Requesting other URLs for the same asset (with different transformations) will work as the error cache is only for a particular URL, so using a different transformation once the original image is uploaded will work also, e.g. adding a no-op transformation such as a_0.

    We have a support article which you can find here that also describes such cases:
    https://support.cloudinary.com/hc/en-us/articles/202520452-I-m-getting-a-404-or-other-40x-erros-for-my-transformed-image-while-other-versions-of-that-image-work

    We recommend only requesting transformed/derived images after the original has been uploaded/available, and using the Upload API response or a webhooks notification to update your application's database with the details of an image before trying to access it.

    If that's not possible then we suggest making use of placeholder/default images. This allows you to specify an image that will be used if the 'original' doesn't exist in your account at the time of the request. This way you won't get any errors returned and after the missing original is uploaded (and the 'invalidate' parameter is set to 'true' on the upload) we'll use the original image for future requests.

    If you can send me the URLs that needs the cache invalidated then I can invalidate them for you. Feel free to open a direct ticket referencing this if you are not comfortable sharing it here.

    Best regards,
    Thomas

    Developer Support Engineer
    Customer Success team
    Cloudinary UK


    Helpful Links For You
    💬 Share questions, connect with other users in our Cloudinary Community forums and Discord server!
    🧑‍🎓 Join our Cloudinary Academy for free courses, workshops and other educational resources.
    📄 Read our documentation for in-depth details on Cloudinary product features and capabilities
    📰 Check out the Cloudinary blog for the latest company news and insights

  • dalusel
    dalusel Member Posts: 14
    edited May 17
    Options

    Thanks, I've discovered a method to generate placeholder thumbnails for videos prior to their deletion from Cloudinary. These thumbnails will be utilized if the derived transformation yields a 404 error.

    On the other note, while using Cloudinary::Api.delete_resources(public_ids, { all: true, resource_type: 'video' }) , the max public_ids I can supply is 100 which is fair enough but is there a rate limit on this API call?