Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logging of storage operations #1449

Open
tarjei opened this issue May 8, 2024 · 7 comments
Open

Logging of storage operations #1449

tarjei opened this issue May 8, 2024 · 7 comments

Comments

@tarjei
Copy link
Contributor

tarjei commented May 8, 2024

Feature Request

If storage fails, then the errors should be logged.

For example in the FlySystemStorage module we got:


    protected function doRemove(PropertyMapping $mapping, ?string $dir, string $name): ?bool
    {
        $fs = $this->getFilesystem($mapping);
        $path = !empty($dir) ? $dir.'/'.$name : $name;

        try {
            $fs->delete($path);

            return true;
        } catch (FilesystemException $e) {
            return false;
        }
    }

This error is not propagated anywhere. It would be very usefull if it at least got logged.

Q A
New Feature yes
RFC no
BC Break no

Summary

Log errors in storagehandlers.

@garak
Copy link
Collaborator

garak commented May 8, 2024

You can easily add a listener for the exception and perform whatever you want (logging, etc.)

@tarjei
Copy link
Contributor Author

tarjei commented May 8, 2024

@garak how? It seems to me it is just swallowed... :)

@garak
Copy link
Collaborator

garak commented May 8, 2024

Sorry, I misread, you're right.
I think the method should throw the same CannotWriteFileException thrown by the doUpload method.
By the way, the previous exception should be passed.

@tarjei
Copy link
Contributor Author

tarjei commented May 8, 2024

@garak no problem :) This would require a try catch in UploadHandler wouldn't it? So that the exception is caught there and an event emitted? If the exception is thrown all the way then that would be a BC break - no?

@garak
Copy link
Collaborator

garak commented May 8, 2024

On second thought, it's better to keep it like it is now.
The handler expects an exception for the upload and doesn't expect it from the remove.

Maybe you can exploit a combination of pre-remove and post-remove events to reach your goal.
Otherwise, redefining your own storage is always a possibility.

@tarjei
Copy link
Contributor Author

tarjei commented May 8, 2024

I would like to politely disagree. Debugging config errors etc in a storage handler is impossible the way it is setup now with silent fail.

The simplest solution would be a PR where the StorageHandlers get a logger and log each execption. This surfaces the error but does not change the overall behavior of the system. IMHO the other option is to let the UploadHandler catch the exception and emit an event.

@garak
Copy link
Collaborator

garak commented May 8, 2024

I'd rather avoid adding a new dependency.
Let's go with the new event.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants