Rollback fault после первой Portfolio write: в PortfolioRepository.publish (транзакция: claimed → tbankPortfolio.upsert → valueHistory → valuePoint) нет честного сбоя посередине. Текущие mockRejectedValueOnce(new Error('db')) падают до транзакции. FK и upsert не дают сбоя внутри без подмены.
Доказательство claimed-fence: мутант на отключение claimed не ловится ни одним тестом. Прямой тест на отказ при устаревшем attempt не моделируется: FK tbankSyncWork -> tbankConnection и каскад put не допускают состояния «работа есть, соединение уже сменилось».
Решение, которое нужно принять
Разрешена ли тестовая инъекция сбоя (spy на делегаты транзакции, test-only seam в репозитории или внедрение фабрики клиента)? В проекте прецедента spy на делегаты $transaction нет. Issue #63 запрещает новый fixture framework, поэтому вариант должен быть минимальным.
Критерии готовности (после решения)
Сбой после первой записи tbankPortfolio откатывает snapshot и points (проверка по БД).
Мутант на отключение claimed ловится тестом.
Без изменения продакшен-логики ради тестов, либо явное согласование seam.
Остаток из #63 (см. её комментарий).
## Проблема
1. Rollback fault после первой Portfolio write: в `PortfolioRepository.publish` (транзакция: claimed → tbankPortfolio.upsert → valueHistory → valuePoint) нет честного сбоя посередине. Текущие `mockRejectedValueOnce(new Error('db'))` падают до транзакции. FK и upsert не дают сбоя внутри без подмены.
2. Доказательство `claimed`-fence: мутант на отключение `claimed` не ловится ни одним тестом. Прямой тест на отказ при устаревшем attempt не моделируется: FK `tbankSyncWork -> tbankConnection` и каскад `put` не допускают состояния «работа есть, соединение уже сменилось».
## Решение, которое нужно принять
Разрешена ли тестовая инъекция сбоя (spy на делегаты транзакции, test-only seam в репозитории или внедрение фабрики клиента)? В проекте прецедента spy на делегаты `$transaction` нет. Issue #63 запрещает новый fixture framework, поэтому вариант должен быть минимальным.
## Критерии готовности (после решения)
- Сбой после первой записи `tbankPortfolio` откатывает snapshot и points (проверка по БД).
- Мутант на отключение `claimed` ловится тестом.
- Без изменения продакшен-логики ради тестов, либо явное согласование seam.
Решение владельца: тестовая инъекция сбоя через jest.spyOn в integration-тесте (обёртка $transaction/делегата внутри tx), без изменения production-кода и без нового fixture framework.
Решение владельца: тестовая инъекция сбоя через `jest.spyOn` в integration-тесте (обёртка `$transaction`/делегата внутри tx), без изменения production-кода и без нового fixture framework.
Сделано в #146 (squash в develop): rollback после первой записи point проверяется по БД; claimed fence — на реальной БД (stale attemptId, complete, invalidToken). Мутанты описаны в PR. Production-код не менялся.
Сделано в #146 (squash в develop): rollback после первой записи point проверяется по БД; claimed fence — на реальной БД (stale attemptId, complete, invalidToken). Мутанты описаны в PR. Production-код не менялся.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Остаток из #63 (см. её комментарий).
Проблема
PortfolioRepository.publish(транзакция: claimed → tbankPortfolio.upsert → valueHistory → valuePoint) нет честного сбоя посередине. ТекущиеmockRejectedValueOnce(new Error('db'))падают до транзакции. FK и upsert не дают сбоя внутри без подмены.claimed-fence: мутант на отключениеclaimedне ловится ни одним тестом. Прямой тест на отказ при устаревшем attempt не моделируется: FKtbankSyncWork -> tbankConnectionи каскадputне допускают состояния «работа есть, соединение уже сменилось».Решение, которое нужно принять
Разрешена ли тестовая инъекция сбоя (spy на делегаты транзакции, test-only seam в репозитории или внедрение фабрики клиента)? В проекте прецедента spy на делегаты
$transactionнет. Issue #63 запрещает новый fixture framework, поэтому вариант должен быть минимальным.Критерии готовности (после решения)
tbankPortfolioоткатывает snapshot и points (проверка по БД).claimedловится тестом.Решение владельца: тестовая инъекция сбоя через
jest.spyOnв integration-тесте (обёртка$transaction/делегата внутри tx), без изменения production-кода и без нового fixture framework.Сделано в #146 (squash в develop): rollback после первой записи point проверяется по БД; claimed fence — на реальной БД (stale attemptId, complete, invalidToken). Мутанты описаны в PR. Production-код не менялся.