Kotlin wrapper fix: use File direct access to fix the FileNotFound exception

[adalpari]

Problem
The Kotlin wrapper was experiencing file access issues during media uploads, throwing MediaUploadRequestExecutionException.MediaFileNotFound exceptions when attempting to upload files. This prevented successful file uploads through the WordPress REST API implementation.

Solution
This PR resolves the file access issue by modifying the Kotlin wrapper to use direct File access instead of the previous file handling approach. The change ensures that files can be properly accessed and read during the upload process, eliminating the MediaFileNotFound exception.

[Copilot]

Pull Request Overview

This PR fixes a FileNotFound exception in the Kotlin wrapper by changing how media files are accessed during upload requests. The change removes resource-based file loading in favor of direct file system access with proper validation.

• Replaces classloader resource loading with direct File constructor access
• Adds explicit file readability validation using canRead()
• Simplifies the file handling logic while maintaining error handling

[oguzkocer]

@adalpari It looks like the create media integration test is broken:

java.lang.AssertionError: Request wasn't successful: MediaFileNotFound(filePath=/test-data/test_media.jpg)

[adalpari]

@adalpari It looks like the create media integration test is broken:

java.lang.AssertionError: Request wasn't successful: MediaFileNotFound(filePath=/test-data/test_media.jpg)

Yes, I saw it. And actually, that's the reason why the function was not working, but the test was. The function was getting the file as a resource of the project, which is available ONLY inside the project or in test build. However, in prod build we are actually sending external files paths.

Do you happen to know the absolute path of the file? Maybe the test will work that way.

There are other two alternatives, but since I cannot build the project I am a bit limited:

1. Create a FileResolver and inject it inside WpRequestExecutor so I can mock it in test to get return the proper file.
2. Add the File as a parameter of MediaUploadRequest instead of the path. So the client will decide how to resolve it.

As said I am a bit limited, specially for option 2.

Wdyt?

[oguzkocer]

I made a minor suggestion to use interface over open class.

[oguzkocer]

Shouldn't this be an interface?

[adalpari]

Good point!

[oguzkocer]

Is this due to if (file == null || !file.exists() || !file.isFile || !file.canRead()) condition?

It's fine to suppress it, but I find it weird that it's causing a warning for this 😕

[adalpari]

Yes it's because of that. I can extract the file checks though.

[adalpari]

I've now made the changes you suggested