6.5 KiB
Purpose
Задаёт независимое от открытых экранов часовое обновление инвестиционных данных пользователя и наблюдаемый результат последней попытки при частичных сбоях.
ADDED Requirements
Requirement: Часовой обход личных инвестиционных данных
Backend SHALL начинать первый обход после успешного подключения T-Bank и последующие обходы не ранее чем через 60 минут от начала предыдущей попытки для подключения. При старте после простоя он MUST учитывать время последней попытки, выполнять не более одного актуального обхода и MUST NOT воспроизводить пропущенные часы. Если попытки ещё не было и данных нет либо они старше часа, обход MUST начинаться при старте. Неуспешная попытка MUST NOT повторяться ранее следующего часового срока даже после перезапуска. Перекрывающиеся обходы MUST NOT выполняться; если срок настал во время ещё идущего обхода, соответствующий запуск пропускается.
Обход MUST проверять доступные счета и обновлять портфель каждого доступного счёта, изменяемый хвост операций и будущие события по бумагам текущего портфеля. Он MUST NOT повторно загружать уже полные прошлые интервалы операций, завершённые свечи или полную рыночную историю. Он MUST NOT зависеть от открытого frontend. Смена подключения MUST NOT позволять завершившейся поздно попытке старого подключения изменять личные данные или время их успеха.
Scenario: Первое подключение между часовыми запусками
- WHEN пользователь успешно подключает T-Bank после запуска backend
- THEN первый обход начинается без ожидания следующего календарного часа, а следующий допускается через час от начала первого
Scenario: Рестарт после неуспешной попытки
- WHEN backend перезапускается до истечения часа после неуспешного обхода с отсутствующими данными
- THEN обход не повторяется при рестарте, а последнее успешное состояние остаётся доступным согласно действующей границе доступа
Scenario: Перекрытый часовой срок
- WHEN начатый час назад обход всё ещё выполняется
- THEN второй обход не запускается, а пропущенная попытка не ставится в очередь сразу после завершения первой
Scenario: Возобновление после простоя
- WHEN backend не работал несколько часов и после старта обнаружил, что последняя попытка старше часа
- THEN он запускает только один текущий обход без синтетических прошлых обновлений
Requirement: Сохранность и статус последней попытки
Успех одного счёта или источника MUST сохраняться независимо от ошибки другого; неполный либо неуспешный результат источника MUST NOT заменять его последнее успешное состояние или время. Backend SHALL предоставлять аутентифицированному пользователю статус только его последнего обхода: время начала, состояние (выполняется, полностью успешен, частично успешен или неуспешен) и проблемные счета и разделы без чувствительных сведений. Кабинет MUST показывать результат, время и проблемные счета/разделы при частичном успехе; отсутствие состоявшейся попытки MUST быть отличимо от успеха. Статус не предоставляет возможности начать синхронизацию с frontend.
Scenario: Ошибка одного счёта
- WHEN портфели двух счетов обновились, а третий не обновился
- THEN новые данные первых двух сохраняются, у третьего остаётся последнее успешное состояние, а статус обхода обозначает частичный успех и проблемный счёт
Scenario: Ошибка событий при успешных портфелях
- WHEN все портфели обновлены, но событие одной бумаги не обновилось
- THEN последний успешный прогноз сохраняется и статус обхода обозначает частичный успех с проблемным разделом
Scenario: Пользователь другого подключения запрашивает статус
- WHEN авторизованный пользователь запрашивает статус чужого обхода либо попытки старого подключения
- THEN система не раскрывает детали чужой или прежней границы доступа