Packages / Cloudinary Storage: Fix move file when ROOT is defined

[joselcvarela]

Scope

We are using Cloudinary as storage and we found that when using STORAGE_<LOCATION>_ROOT it throws an error when editing an image.

{
  "errors": [
    {
      "message": {
        "extensions": {
          "stack": "Error: Can't move file \"temp_0434757f-7d0b-4f88-93fb-8eec237e0327.jpg\": Resource not found - temp_0434757f-7d0b-4f88-93fb-8eec237e0327\n    at DriverCloudinary.move (file:///directus/packages/storage-driver-cloudinary/dist/index.js:239:13)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at FilesService.uploadOne (/directus/api/src/services/files.ts:159:4)\n    at Multipart.<anonymous> (/directus/api/src/controllers/files.ts:109:23)"
        }
      },
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "stack": "Error: Can't move file \"temp_0434757f-7d0b-4f88-93fb-8eec237e0327.jpg\": Resource not found - temp_0434757f-7d0b-4f88-93fb-8eec237e0327\n    at DriverCloudinary.move (file:///directus/packages/storage-driver-cloudinary/dist/index.js:239:13)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at FilesService.uploadOne (/directus/api/src/services/files.ts:159:4)\n    at Multipart.<anonymous> (/directus/api/src/controllers/files.ts:109:23)"
      }
    }
  ]
}

It looks like the move operation does not take the root folder into consideration:
https://github.com/directus/directus/blob/main/packages/storage-driver-cloudinary/src/index.ts#L199-L204

Although delete already handles this:
https://github.com/directus/directus/blob/main/packages/storage-driver-cloudinary/src/index.ts#L365-L370

So in this PR we just apply the same approach in order to get the proper file path.

What's changed:

• Fix paths on move operation for Cloudinary storage. In other words, fix saving edited image when using ROOT with Cloudinary storage

Potential Risks / Drawbacks

• None 🤔

Review Notes / Questions

• N/A

[changeset-bot]

🦋 Changeset detected

Latest commit: 75de80c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 13 packages

Name	Type
@directus/storage-driver-cloudinary	Patch
@directus/storage	Patch
@directus/api	Patch
@directus/errors	Patch
@directus/storage-driver-azure	Patch
@directus/storage-driver-gcs	Patch
@directus/storage-driver-local	Patch
@directus/storage-driver-s3	Patch
@directus/storage-driver-supabase	Patch
directus	Patch
@directus/extensions-registry	Patch
@directus/memory	Patch
@directus/validation	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[rijkvanzanten]

Looks like the unit tests are failing for the cloudinary driver. Mind taking a look @joselcvarela ?>

[joselcvarela]

Looks like the unit tests are failing for the cloudinary driver. Mind taking a look @joselcvarela ?>

Yeah, I was already looking into it and I just pushed new changes to fix the tests 👍

[paescuj]

Can confirm it fixes that specific issue 🚀
Although, I've noticed that the edited version of the image isn't actually persisted (regardless of ROOT). However, this seems to be unrelated, as it was already the case before. Will open a separate issue 👍

[joselcvarela]

Can confirm it fixes that specific issue 🚀 Although, I've noticed that the edited version of the image isn't actually persisted (regardless of ROOT). However, this seems to be unrelated, as it was already the case before. Will open a separate issue 👍

I also have experienced this, but according to Cloudinary documentation, signed URLs are not invalidated https://arc.net/l/quote/rbyeysrn

Since we are using signed URLs to access private assets, we could create a different file on Cloudinary instead of reusing the existent one, but the existent one is based on the primary key of the file so not sure if this is the right approach to follow.

[paescuj]

Can confirm it fixes that specific issue 🚀 Although, I've noticed that the edited version of the image isn't actually persisted (regardless of ROOT). However, this seems to be unrelated, as it was already the case before. Will open a separate issue 👍

I also have experienced this, but according to Cloudinary documentation, signed URLs are not invalidated https://arc.net/l/quote/rbyeysrn

Since we are using signed URLs to access private assets, we could create a different file on Cloudinary instead of reusing the existent one, but the existent one is based on the primary key of the file so not sure if this is the right approach to follow.

Good catch, this seems to be exactly it! I've created #22556, let's discuss over there 👍
In the meantime, we can still merge this pull request as it already improves the situation.