Панбагон. Ошибка 500 при изменении времени доставки оплаченного заказа

У Партии еды есть пара проблем в личном кабинете. Одна из них — стоит тебе что-то поменять в заказе, как сбрасывается время доставки. Когда ты делаешь заказ и оформляешь подписку, все параметры сохраняются. И вот я установила короткий интервал (с 12 до 16, например), пару раз мне привезли еду. А потом я добавила в партию завтраки и в воскресенье получила смс «курьер приедет с 12 до 21». Эээээээ о_О

Хотя сейчас попробовала — не воспроизвелось. Может, уже исправили. Не суть. В эти выходные снова пришла смс «с 12 до 21», что оказалось очень неудобно. Я хотела один ужин сделать на обед, а курьер приехал только в четыре...

Решила уменьшить интервал на следующий раз. Залезла в аккаунт, «изменить заказ», меняю время, сохраню — не сохраняется.

1. Изменить

Обновляю страницу, включаю F12 (панель разработчика). Ага, ошибка 500.

2. Оплаченный заказ

Всегда ли так?


Этот заказ уже оплачен. Открываю следующий заказ, редактирую время, сохраняю — система доооооолго думает (минуту, наверное), но у меня открыта панель разработчика и ошибок там нет. Наконец, сайт прочухался и изменения мне все сохранил. Значит, проблема в уже оплаченном заказе! Ну или надо локализовать еще, но для этого нужны еще аккаунты, которых у меня нет ))))

Давайте оформим баг по шаблону:

*************************************************************

Ошибка 500 при изменении времени доставки оплаченного заказа

Шаги

1. Открыть страницу заказов — https://partiyaedi.ru/account# (авторизоваться по телефону)
2. Нажать «Изменить» у уже оплаченного заказа, см рис «1. Изменить»
3. Изменить время доставки, например, сдвинуть правый бегунок, с 21 на 20.
4. Нажать на кнопку «Сохранить»

Результат

Бегунок сохранения вращается вечно, в консоли видим ошибку 500, см рис «2. Оплаченный заказ»

Ожидаемый результат

Заказ сохраняется, ошибок нет, как это происходит при изменении неоплаченной партии

*************************************************************

Помните про обоснования багов? Мы обсуждали это в последние 5 минут доклада на DUMP. Когда у нас ошибка на сервере, тут не надо обосновывать, но надо написать, что именно мы ожидаем.

Баг интересен в локализации. Вот я напоролась на него, стоит ли сразу репортить? Нет, надо проверить теории:

• Всегда ли падает при изменении заказа?
• А если я ничего не меняла?
• А если уменьшила время не до минимума, а чуть-чуть?
• А если время не трогала, а изменила адрес или наполнение?
• А для любых заказов так или только для оплаченных?

Теории проверяются за 5 минут, но позволяют сделать кое-какие выводы и точнее локализовать проблему, чтобы потом о ней сообщить. Иначе поднимешь панику "аааааа, заказы менять нельзя, ошибка 500, КАКОЙ КОШМАР", а разработчик скажет «ниче не знаю, у меня все работает» ツ

См также:

Шаблон бага → использовался в статье

Шаблон улучшения — Как продумывать свое улучшение с примером, когда это приводит к отказу от постановки задачи.

Как заводить задачи в баг-трекер → подробнее о том, как ставить задачу и заполнять обязательные поля.

Паттерны и антипаттерны обоснования багов → видео с DUMP, переписанное на нормальный микрофон

PS — добавила пост в общую копилку багов.