Почему не всегда срабатывает код?

Question

[Валерий Павлов]

Есть сайт на Laravel, к нему подключена платежка.
Есть код, который срабатывает в случае успешного пополнения.

public static function updateDataUser($waitingPayment, $balance)
{

    try {
        DB::beginTransaction();
        $waitingPayment = HistoryPayment::find($waitingPayment->id);
        if ($waitingPayment->status_transaction === 'success') {
            return false;
        }

        $waitingPayment->status_transaction = 'success';
        $waitingPayment->save();

        $user = User::find($waitingPayment->user->id);

        $user->balance += $balance;
        $user->save();

        DB::commit();

    } catch (\Throwable $e) {
        DB::rollBack();
        return false;
    }
    ChangeBalance::dispatch($user->id, $user->balance);
    return true;
}

Как видно, сначала идет присвоение статуса 'success' к операции, а потом уже увеличиваем баланс пользователя.
Проблема в том, что иногда бывает такое, когда статус 'success' присваивается, а баланс просто не прибавляется. Я не понимаю почему это происходит.

Человек пишет в тех.поддержку, мы смотрим на транзакции, видим успешную, а баланса нету и истории покупок тоже. Т.е. реально не засчитали и мы вручную его пополняем. Но естественно это надо исправить.

В чем может быть проблема?

Comments

[Akina]

А где у Вас контроль успешности операции? не успешности выполнения программы, не успешность выполнения запроса, а именно выполнение операции запроса? Ведь иногда выполнение запроса с "нулевым" результатом - это не ошибка, а штатное событие...

Включите General Log и отсмотрите по проблемным транзакциям, какие именно запросы поступали на сервер MySQL.

[Akina]

А где у Вас контроль успешности операции? не успешности выполнения программы, не успешность выполнения запроса, а именно выполнение операции запроса? Ведь иногда выполнение запроса с "нулевым" результатом - это не ошибка, а штатное событие...

Включите General Log и отсмотрите по проблемным транзакциям, какие именно запросы поступали на сервер MySQL.

[Валерий Павлов]

Akina, Контроль успешности операции? Это что, не совсем понимаю.
И еще, у меня же success статус операции ставится, а баланс не прибавляется. Т.е. все успешно доходит до этого кода, он начинает выполняться и даже выполняется, но не полностью.

[Валерий Павлов]

Akina, Контроль успешности операции? Это что, не совсем понимаю.
И еще, у меня же success статус операции ставится, а баланс не прибавляется. Т.е. все успешно доходит до этого кода, он начинает выполняться и даже выполняется, но не полностью.

[Akina]

Контроль успешности операции? Это что, не совсем понимаю.

Простейший пример - передача некорректного значения, приводящего к усечению. Это не ошибка, это предупреждение. И соответственно ни ошибка в программу не упала, ни транзакция не откатилась, а в данных лажа. Или там триггер подал сигнал, а хранимая процедура его не отресигналила... Подобных событий, при которых желаемая операция не выполняется или выполняется не так, как требуется, но без падения по ошибке - вагон и маленькая тележка. А твоя программа о таких событиях ни сном ни духом.

Или вот например что будет, если User::find ничего не найдёт, или наоборот - найдёт больше одной записи? я лично фиг знает, ибо в ларавелях ноль - но приведёт ли это к ошибке кода и откату транзакции?

[Максим Федоров]

DB::beginTransaction();
if ($waitingPayment->status_transaction === 'success') {
       return false;
}

Ну открыта и открыта, возвращаемся, ребята

[Валерий Павлов]

Максим Федоров, ?

[Максим Федоров]

Иван, у вас открывается транзакция, и выход без ее закрытия в одном из кейсов
то есть транзакция будет висеть

[Валерий Павлов]

Максим Федоров, У меня же закрывается транзакция. С чего вы взяли? Можете пожалуйста пояснить.

[Валерий Павлов]

Максим Федоров, Или вы имеете ввиду, что я её не закрываю, в случае если статус = success?

[Максим Федоров]

Иван, ну как вы закрыли, если вы сделали return до закрытия?!

Если бы была секция finally в try/catch, то я понял бы вас, а тк ничего не закрыто

[Максим Федоров]

Иван,

я её не закрываю, в случае если статус = success?

да, это и имею в виду

[Валерий Павлов]

Максим Федоров, Даже если так, проблема же не в этом. Потому-что статус success ставится, т.е. в случае если status != sucess, то он идет дальше, ставит его успешный, но не всегда пополяет баланс.

Answer 1

[Вячеслав Плиско]

Добавьте логирование, чтобы вы знали что в рамках именно этого $waitingPayment->id поменяли статус и баланс.
п.с. Апдейты надо делать атомарные,
User::where('id', $waitingPayment->user->id)->increment('balance', $balance);
Событие ChangeBalance::dispatch лучше тоже обсервить на уровне модели, а то в другом месте забудете выбросить и сломаете логику.
$waitingPayment->status_transaction - инкапсулируйте всю логику внутри модели, а то вы дважды делаете сравнение со строкой и это потенциально хрупкий код, в случае опечатки даже не заметите.

Answer 2

[Руслан .]

Вот тут немного странно сделано:
DB::beginTransaction();
$waitingPayment = HistoryPayment::find($waitingPayment->id);
if ($waitingPayment->status_transaction === 'success') {
return false;
}

Открываем транзакцию, чекаем что status_transaction === 'success' и выходим не закрывая её и не откатывая. Может вынести проверку до открытия транзакции.
Просто открытая тут транзакция может, где-то далее не явно использоваться и возможно влиять на то, что что-то потом откатывается при rollback, что не должно откатывать я.

Есть ещё вызов
ChangeBalance::dispatch($user->id, $user->balance);
Он за пределами основной транзакции и не в try, может он влиять на баланс, например если внутри у него ошибка случается?

Comments

[Валерий Павлов]

ChangeBalance::dispatch($user->id, $user->balance); - это просто чтобы уведомление пришло, что обновился баланс.

А касаемо лишний проверки, как я понял (не я писал код), это чтобы если вдруг функция вызовится два раза, предотвратить это. Т.е. если она уже успешна, значит ничего не делаем.