Прежде чем дать AI-агенту доступ к сайту: права, повторы и потерянные правки

[rumataestor]

Удачи! Надеюсь, следующая статья будет уже о практических испытаниях на живом MODX. Всё-таки самое интересное — посмотреть, что из этого получится в реальных условиях. Теория и тесты — это хорошо, но практика иногда преподносит такие сюрпризы, что мало не покажется.

[evgenijkarnauhov]

Спасибо. Надеюсь, что в скором времени что-то смогу написать и об этом.

[ig_novvv]

Я поймал похожую историю с повторами в своей обвязке API. Пакетная отправка создала задания, но ответа не дождалась: сервис поставил их на паузу из-за нехватки баланса. Дальше включилась поштучная отправка и создала те же задания заново. Вместо 16 запросов в очереди оказалось 32. Теперь я сохраняю идентификатор уже созданного задания, чтобы поштучный путь забирал его, и останавливаю канал, если сервис сообщает о паузе.

[evgenijkarnauhov]

Вот здесь, кстати, интересный момент. Таймаут ведь ещё не означает, что операция не выполнилась. Поэтому я бы разделял состояния FAILED и UNKNOWN. Если подтверждение не пришло, это ещё не повод запускать поштучную отправку. Сначала неплохо бы выяснить судьбу первоначального запроса, если API это позволяет.

А у вас есть возможность проверить, какие именно задания создались, если пакетный запрос вообще не вернул ответа? Или приходится ориентироваться только на локально сохранённые идентификаторы?

[rumataestor]

Тут, по-моему, проблема чуть глубже. У вас два механизма отправки независимо создают задания. Я бы разделил создание задания и его отправку: единый реестр с уникальными ключами и состояниями, а пакетная и поштучная отправка — просто разные способы доставки.

При потере ответа задание переходит в UNKNOWN, а не создаётся заново. При ошибке баланса срабатывает circuit breaker. Правда, без поддержки идемпотентности на стороне API полностью исключить дубли всё равно не получится. Вот это уже интересная задачка.