# Предложения о корректировках в жизненный цикл Драйва
Во время глубокого изучения и продумывания описанного жизненного цикла Драйва, возникло множество важных для рассмотрения замечаний в первую очередь касающихся безопасности и стабильности системы. Конкретизируя, найденные сложности касаются каждого основного события в Драйве(Bulk, Download, Verify, Execute), в которых явно прослеживаются общие точки требующие дополнительных синхронизаций и проверок между репликаторами на уровне их протокола. Сам же документ нацелен на подробное описание этих точек.

## Проверка корректной исполнимости события
### Проблематика
Для рассмотрение проблематики, возьмем за основу Bulk событие. Репликаторы в неопределенной последовательности обнаруживают появления нового Bulk события, запущенного владельцем на определенной высоте сети. По нынешней модели, каждый репликатор без каких либо проверок запускает выкачку изменений с владельца, не удостоверившись в том что другие репликаторы также получили событие с теми же параметрами => запустили выкачку на своей стороне корректно. Отсутствие проверок на старте выполнения событий и является корневой проблемой, которая может привести к неконтролируемым, а главное не обрабатываемым кейсам, уменьшая общее юзабилити.

### Примеры проблем
На том же Bulk событии рассмотрим примеры описанных кейсов. Самым простым примером будет отсутствие подключения к одному или нескольким репликаторам, причем какая-то часть имеет связь с конкретным узлом, а какая-то нет. Подобный случай приводит к неравномерному распространению квитанций между узлам => вероятность прийти к консенсусу относительно квитанций во время следующего Bulk события непредсказуемо уменьшается. Помимо проверки подключений, каждому репликатору есть смысл сверять корректность входных данных с другими репликаторами перед стартом события, дабы не стать заложником недобросовестного валидатора, раз репликаторы в нашей системе не обязаны быть валидаторами. Другой неприятный момент - это неочевидность подобных кейсов, ведь сразу очень тяжело рассмотреть все возможные сложности вызванные проблемами в соединение, или же несоответствия входных данных на каждом узле по любым причинам.

### Решения под кейс vs обощенное решение
На первый взгляд, на каждый описанный случай можно отдельно придумать свое решение. Однако, все они будут решать проблемы в частности, когда могли бы быть обнаружены и предотвращены еще на старте, проверкой что все репликаторы на связи и входные данные у всех идентичны. Таким образом, все описанные и любые другие неочевидные проблемы сведутся к одному месту, позволяя разом их всех покрыть, описав единую логику для решения, вместо хаотичного затыкания грубыми фиксами по мере появления. Когда же сама логика решения во многих случаях сводится к определению недобросовестного или неактивного по таймауту репликатора, позволяя выявить его на ранних стадиях.

### Итог
Абстрагируясь от Bulk, аналогичные видимые проблемы можно выявить подставив любое другое событие вместо. Как и можно отыскать множество других неочевидных, которые связаны со спецификой конкретного ивента. В итоге, мы видим первый общий паттерн у всех ивентов - необходимость репликаторам заранее проверять самим и сверять между собой возможность корректного выполнения логики события, а в случае проблем удалять, дожидатся или делится(под вопросом) состоянием с другими репликаторами.

## Выполнение и обработка промежуточных результатов события

## Обработка и отправка конечных результатов