Thanks 👍

I need to revert this one since it's a breaking change on that interface. Sorry!

Thank you @taylorotwell ! I was just about to comment on it, because of e.g this❤️

I was going to do that today also, sorry about that! I didn't consider there were outside consumers of the interface, my bad! I'll be more careful in future.

I was going to do that today also, sorry about that! I didn't consider there were outside consumers of the interface, my bad! I'll be more careful in future.

I think it was very good thinking even though 😀

@dshafik please consider sending it to master, it is indeed a nice contribution

@dshafik I was thinking.

Maybe it could be possible to implement a new function e.g transactionWithCallback() 🤔

I didn't think it through quite yet - but i really like the idea of onFailure() callback in the trasaction

When looking at the feature in more detail trying to replicate it for the MongoDB integration (which has slightly different transaction handling due to how transactions work in MongoDB), I wasn't quite sure why the callback was preferable to a try-catch block:

try {
    DB::transaction(function () {
        // TODO: World peace
    });
} catch (Throwable $e) {
    // TODO: Save the world
}

I'm sure I'm missing some part of this, maybe @dshafik could help me understand why the above isn't sufficient?

I created a lightweight package which can be extended (since it is chainable instead of handling it with params):

Basically it wraps DB::transaction() so that we can use it as

$result = TransactionBuilder::make()
    ->attempts(3) // number of attempts
    ->run(function () {
        // your transaction logic
        return 'test';
    })
    ->onFailure(function ($exception) {
        // your onFailure callback logic
        logger()->error($exception->getMessage());
    })
    ->result();

https://github.com/moe-mizrak/transaction-builder