This PR addresses an issue with exception handling in BackupJob.
As both the BackupCommand command and BackupJob are handling exceptions the result is both send the failure notification when they deem the process to have failed.
With these changes BackupCommand will exclusively handle notifying the user if a failure scenario occurs. Due to the command being able to retry itself it makes the most sense to allow it to determine when it considers the process to have failed.
Before these changes the copyToBackupDestinations method of BackupJob would fire the backup failed event and pass the destination as a parameter.
To ensure behavior remains the same, I have added the BackupFailed exception which acts as a decorator with a public $backupDestination property which is used to set the same property in the backup failed event.
The backup destination property is set by chaining on the exception.
BackupJob still handles success notifications and informative (including error) output to the console, we would need to completely decouple the job from the command to change this behavior, which I do not believe has any benefit to the package.
PHPStan raised an issue with getPrevious() returning Throwable|null as BackupHasFailed event accepts Exception - to fix this an @method has been added to BackupFailed. This can be replaced with a previous(): Exception method if you prefer.
freekmurze
commented
1 year ago
Fixes #1662
Summary
This PR addresses an issue with exception handling in BackupJob.
As both the
BackupCommandcommand andBackupJobare handling exceptions the result is both send the failure notification when they deem the process to have failed.With these changes
BackupCommandwill exclusively handle notifying the user if a failure scenario occurs. Due to the command being able to retry itself it makes the most sense to allow it to determine when it considers the process to have failed.Before these changes the
copyToBackupDestinationsmethod ofBackupJobwould fire the backup failed event and pass the destination as a parameter.https://github.com/spatie/laravel-backup/blob/f4a2abc673ed61447ca748d02e9cc8be16e1c485/src/Tasks/Backup/BackupJob.php#L300
To ensure behavior remains the same, I have added the
BackupFailedexception which acts as a decorator with a public$backupDestinationproperty which is used to set the same property in the backup failed event.The backup destination property is set by chaining on the exception.
https://github.com/spatie/laravel-backup/blob/c394924f2016f709913e7b9894a7ed17898bdd4a/src/Tasks/Backup/BackupJob.php#L304
The notification receives the original exception for the user to debug.
https://github.com/spatie/laravel-backup/blob/dc70da6abab42f003eaa873bba792f82ffbda92a/src/Commands/BackupCommand.php#L84
Possible Concerns
BackupJobstill handles success notifications and informative (including error) output to the console, we would need to completely decouple the job from the command to change this behavior, which I do not believe has any benefit to the package.getPrevious()returningThrowable|nullasBackupHasFailedevent acceptsException- to fix this an@methodhas been added toBackupFailed. This can be replaced with aprevious(): Exceptionmethod if you prefer.