Изменение модели ИИ для выполняющейся задачи является распределенной операцией, а не простым обновлением настроек. Оно включает чтение текущей задачи, подготовку учетных данных, запрос на перезапуск, получение результата и сохранение активной модели. Когда запросы на переключение моделей пересекаются, порядок завершения может отличаться от порядка запросов, что требует правила для определения того, какое намерение имеет приоритет. Система MonkeyCode записывает попытки переключения моделей с такими деталями, как идентификаторы моделей и идентификаторы запросов. Типичный рабочий процесс включает создание записи о переключении, запрос на перезапуск taskflow, а затем завершение записи о переключении. Однако в ходе анализа исходного кода не были установлены явные контракты на сравнение и обмен (compare-and-swap) или сериализацию для каждой задачи в отношении пересекающихся запросов.Нестабильность подхода "последнее завершение побеждает" демонстрируется сценариями, когда более позднее успешное завершение может перезаписать более раннее из-за сетевых задержек. Сопутствующий симулятор визуализирует эту зависимость от порядка, показывая, что последнее намерение вызывающего абонента не учитывается по своей сути. Для решения этой проблемы предлагается монотонная генерация, присваивающая уникальный номер генерации каждому запросу. Система должна обновлять активную модель только в том случае, если генерация завершения соответствует текущей запрошенной генерации задачи. Эта защита генерации гарантирует, что устаревшие операции не будут применены, даже если они завершатся позже.Защита генерации является лишь частью комплексного протокола, который должен определять контракты для дублирующихся запросов, конкурирующих запросов, поздних успехов, сбоев перезапуска, сбоев процессов, загрузки сессий и привязки учетных данных. Сериализация, например, использование блокировок для каждой задачи, является альтернативой, но вносит сложности, такие как истечение срока действия аренды и справедливость. Модульные тесты должны проверять этот протокол с контролируемым чередованием операций на различных этапах. Инвариант заключается в том, что активная модель всегда должна соответствовать успешному результату для наибольшей не отмененной генерации. Рассмотрение переключения моделей как протокола обеспечивает согласованность между пользовательским интерфейсом, журналами аудита, повторными попытками и сохранением данных.