Issue: --isolated Command Lock Persists After Manual Termination

[azgooon]

Laravel Version

10.48.22

PHP Version

8.3.13

Database Driver & Version

Postgress

Description

I've been working with commands that require the --isolated option to ensure they run exclusively. However, there is something that feels inconsistent when it comes to lock removal:

• When an exception is thrown within the command, Laravel correctly removes the lock from the cache (using Redis in my case).

• But if the process is manually terminated (e.g., with Ctrl+C), the lock remains in Redis and has to be manually cleared before the command can be run again.

I’m looking for guidance on the best approach to ensure that the lock is removed from the cache regardless of how the command is terminated. Ideally, I’d like to avoid using a time-based release, as I need the lock to persist only until the command truly finishes.

I also wanted to add that artisan schedule:clear-cache does not cleare mentioned locks.

Would appreciate any suggestions or best practices on this. Thanks!

Steps To Reproduce

1. Create a command that implements the Isolatable interface.
2. Execute the command using the --isolated option.
3. Terminate the command’s process manually (with i.e kill command).
4. Check the cache to confirm that the lock created during execution remains and has not been removed.

[crynobone]

To detect Ctrl+C would require the `pencil' extension, which is not supported by some environments, including Windows.

[azgooon]

Thanks for the input, @crynobone!

Does the situation change if the command is executed by the scheduler and killed with i.e the kill command
Should the scheduler detect that the process has ended and automatically remove any associated locks?

If that's not feasible, I was thinking about implementing a time-based check (limited to development) to identify any dead processes and their locks, then clean up the ghost locks accordingly.

Thanks,
Tom.