Ð
ну тут нужен кто-то с опытом прикладной бэкенд разработки — как реагировать на то, что сервер не дал ответа.
я уже сказл как - реконнектиться и запрашивать состояние заново.
Size: a a a
2020 December 25
Ð
тут нужен кто-то умеющий слушать
D
ну тут нужен кто-то с опытом прикладной бэкенд разработки — как реагировать на то, что сервер не дал ответа.
Обычно (везде, где я видел), просто юзеру 500-ую кидают и сыпят в логи. Иногда пытаются повторить запрос несколько раз, если он не прошёл.
ВК
Ð
я уже сказл как - реконнектиться и запрашивать состояние заново.
пока транзакция это не сумма перевода N денежных средств, об этом зачастую не думают со стороны разработки.
VY
Ð
тут нужен кто-то умеющий слушать
ad hominem?
Ð
ага
Ð
пока транзакция это не сумма перевода N денежных средств, об этом зачастую не думают со стороны разработки.
некоторые вообще не думают, особенно когда подключают орм, умеющую только круды, и последовательно запускают апдейты, нахлебался я такого
ВК
ох уж эти орм
D
тогда такой вопрос... как с точки зрения бэкенд-разработки обрабатывать такую ситуацию.
ты пишешь код, который делает update в БД. но в процессе апдейта, сетевое соединение до БД может оборваться (не такая уж и редкая ситуация). Как мне кажется класический вариант посчитать это ошибкой и вернуть клиенту ошибку. Но при этом апдейт по факту может завершиться и стейт в БД изменится так как и хотел клиент (хотя клиенту то приложение вернуло ошибку)
ты пишешь код, который делает update в БД. но в процессе апдейта, сетевое соединение до БД может оборваться (не такая уж и редкая ситуация). Как мне кажется класический вариант посчитать это ошибкой и вернуть клиенту ошибку. Но при этом апдейт по факту может завершиться и стейт в БД изменится так как и хотел клиент (хотя клиенту то приложение вернуло ошибку)
На самом деле, с этим вообще нечасто заморачиваются. Приведу пример. Когда Steam подвисает, в нём можно случайно покупку какой-нибудь карточки и т.п. совершить спокойно несколько раз, даже не зная об этом. Получаешь ошибку, а покупка уже по факту прошла
Ð
На самом деле, с этим вообще нечасто заморачиваются. Приведу пример. Когда Steam подвисает, в нём можно случайно покупку какой-нибудь карточки и т.п. совершить спокойно несколько раз, даже не зная об этом. Получаешь ошибку, а покупка уже по факту прошла
и правильно, проблемы веб-коннекшенов это вообще последнее, что должно волновать субд
D
Ð
и правильно, проблемы веб-коннекшенов это вообще последнее, что должно волновать субд
Поэтому я с самого начала и написал: кидаем 500-ую ошибку, логируем и всё. Потом разрабы в логах уже смотрят ошибку и анализируют проблему
D
Это если о бэкенде речь
Ð
кто хоть раз видел веб-систему, которая умеет делать роллбек в своем аплике, ели браузер не смог обновить вьюху и послать подтверждение о том, что он отобразил результат транзакции?
VY
На самом деле, с этим вообще нечасто заморачиваются. Приведу пример. Когда Steam подвисает, в нём можно случайно покупку какой-нибудь карточки и т.п. совершить спокойно несколько раз, даже не зная об этом. Получаешь ошибку, а покупка уже по факту прошла
бывает круче. когда работал в банке, в карточном отделе, когда отказал Front (авторизационная система), то при снятии денег с карточки доступный баланс не снижался.
во время такой аварии несколько умников наснимали в несколько раз больше доступного остатка. правда вечером всё пришло в Backend и всех загнало в глубокий минус (eventually consistent система, ага). единственное, банк не взял штрафные за отрицательный баланс, т.к. их косяк был.
во время такой аварии несколько умников наснимали в несколько раз больше доступного остатка. правда вечером всё пришло в Backend и всех загнало в глубокий минус (eventually consistent система, ага). единственное, банк не взял штрафные за отрицательный баланс, т.к. их косяк был.
D
Ð
кто хоть раз видел веб-систему, которая умеет делать роллбек в своем аплике, ели браузер не смог обновить вьюху и послать подтверждение о том, что он отобразил результат транзакции?
За почти 11 лет разработки я не видел ни разу)
Ð
бывает круче. когда работал в банке, в карточном отделе, когда отказал Front (авторизационная система), то при снятии денег с карточки доступный баланс не снижался.
во время такой аварии несколько умников наснимали в несколько раз больше доступного остатка. правда вечером всё пришло в Backend и всех загнало в глубокий минус (eventually consistent система, ага). единственное, банк не взял штрафные за отрицательный баланс, т.к. их косяк был.
во время такой аварии несколько умников наснимали в несколько раз больше доступного остатка. правда вечером всё пришло в Backend и всех загнало в глубокий минус (eventually consistent система, ага). единственное, банк не взял штрафные за отрицательный баланс, т.к. их косяк был.
ну это совсем уж дичь, когда фронт кэширует и считает все сам, а транзакция не проверяется даже в базе
D
бывает круче. когда работал в банке, в карточном отделе, когда отказал Front (авторизационная система), то при снятии денег с карточки доступный баланс не снижался.
во время такой аварии несколько умников наснимали в несколько раз больше доступного остатка. правда вечером всё пришло в Backend и всех загнало в глубокий минус (eventually consistent система, ага). единственное, банк не взял штрафные за отрицательный баланс, т.к. их косяк был.
во время такой аварии несколько умников наснимали в несколько раз больше доступного остатка. правда вечером всё пришло в Backend и всех загнало в глубокий минус (eventually consistent система, ага). единственное, банк не взял штрафные за отрицательный баланс, т.к. их косяк был.
А почему у них на БД какие-нибудь триггеры не висели?
Ð
А почему у них на БД какие-нибудь триггеры не висели?
фронт же проверял, там до бд не дошло даже, я бы хотел название банка узнать)
VY
а тут вариантов ошибок много. можно случайно снять “on-hold” операции разблокировав суммы. можно случайно “повысить” доступный остаток.
Ð
а можно делать бл на фронте, и потом удивляться десинкам и гонкам