Журнал происхождения видео при генерации через API

Короткий ответ: фиксируйте связь, а не всё содержимое

Полезный audit trail начинается с собственного operation_id приложения. Его связывают с tenant, субъектом действия, типом операции, временем, версией policy и внешним task_id, если тот возвращается. Для входного текста, изображения или шаблона не обязательно хранить полный оригинал в журнале. Достаточно ссылки на ваш защищённый реестр, версии и криптографического отпечатка, рассчитанного по правилам продукта. Так расследование может сопоставить событие с разрешённым исходником, не превращая технический лог в копию пользовательского контента.

Отдельно сохраняйте происхождение разрешения: например, что оператор подтвердил право на материал, либо что система получила ссылку на внутренний кейс согласия. Не записывайте паспортные данные, подписи, изображения лиц или свободный текст согласия в общую телеметрию. Audit trail должен отвечать на вопрос «какое правило и какой идентификатор были проверены», а не раскрывать доказательства каждому разработчику. Права на видео, голос, персонажа и загружаемый материал оценивает заказчик; запись об этом не создаёт права автоматически.

Опишите состояния и неизменяемые события

Состояние задачи удобно строить как последовательность событий: requested, input_checked, policy_approved, submitted, provider_accepted, completed, failed, cancelled и result_revoked. Реальный API может использовать другие названия и не иметь всех статусов, поэтому это модель приложения, а не заявление о контракте RussiaAPI. Каждое событие содержит operation_id, время, источник, безопасный reason code и ссылку на предыдущее событие. Если callback приходит повторно, тот же event_id должен быть распознан как дубль, а не создавать второй результат или новую запись о согласии.

Не меняйте прошлое событие, чтобы «исправить» статус. Добавьте новую запись с причиной корректировки и идентификатором оператора или автоматического правила. Такой подход позволяет различать первоначальный ответ, поздний callback и ручное решение об удалении. Для пользовательского интерфейса выводите только понятное текущее состояние: задача запущена, результат готов, проверка не пройдена или результат отозван. Внутренние маршруты, токены скачивания, webhook headers и детали supplier-ошибки не должны попадать ни в экран, ни в общий audit log.

Свяжите вход, задачу и результат через минимальные идентификаторы

Перед отправкой backend создаёт operation_id и связывает его с версией входа. После документированного server-side вызова он записывает возвращённый task_id как внешнюю ссылку, но не считает задачу завершённой до подтверждённого статуса. Когда появляется результат, приложение создаёт свой result_id, указывает operation_id и хранит объект в контролируемом хранилище. Временный URL поставщика нельзя считать постоянной записью происхождения: он может истечь, поменяться или требовать отдельного доступа. Скачивание результата проходит через ваш проверенный слой авторизации.

Для повторной отправки используйте request_id приложения и собственную идемпотентность. Если пользователь дважды нажал кнопку или сеть оборвалась после отправки, backend возвращает известное состояние операции вместо создания второго task_id. Если endpoint документирует idempotency key, подтвердите его поведение в актуальной документации и тесте; не распространяйте допущение на все video-маршруты. В audit trail полезно видеть связь между повтором и исходным operation_id, но не хранить сырые запросы только ради отладки.

Планируйте доступ, удаление и срок хранения отдельно

Журнал происхождения и файл результата имеют разные сроки и права доступа. Техническое событие может быть нужно команде дольше, чем сам ролик, но оно всё равно подчиняется вашей политике минимизации. Определите, кто может просматривать агрегированную историю, кто может получить защищённый результат и кто уполномочен инициировать удаление. Запрос на удаление добавляет событие deletion_requested, затем фиксирует исход проверки и фактическое удаление в вашем хранилище. Не обещайте, что все внешние копии исчезнут немедленно: условия и сроки сторонних систем подтверждаются отдельно.

Не используйте audit trail как скрытый профиль пользователя. В большинстве случаев достаточно tenant, псевдонимизированного actor_id, типа операции, версии policy и технических идентификаторов. Доступ к журналу требует роли и регистрируется как отдельное событие. Экспорт для поддержки должен отфильтровывать секреты, prompt, Authorization, URL с подписью и персональные поля. Такой экспорт помогает воспроизвести путь задачи, не создавая новую утечку во время расследования.

Проверьте цепочку на тестовой задаче до rollout

Соберите синтетический тест: разрешённый тестовый вход, известная версия policy, искусственный повтор callback, отмена и отказ проверки. Убедитесь, что каждая ветка оставляет понятный набор событий, дубликат не создаёт новую задачу, а пользователь не видит секретные подробности. Проверьте негативный случай: чужой tenant пытается запросить result_id или просмотреть историю. Он должен получить безопасный отказ без существования объекта и без раскрытия чужого task_id.

После smoke test включайте журнал для небольшой группы и измеряйте только полезные показатели: долю несвязанных callback, время до финального статуса, число дублей и успешность удаления в собственном контуре. RussiaAPI не является юридическим регистратором и не подтверждает права на контент. Создайте собственный тестовый ключ в серверном окружении, не передавайте upstream credentials и расширяйте интеграцию лишь после проверки текущего каталога, договора и требований вашего сценария.

Server-side пример

Пример показывает локальный контроллер на сервере. Ключи берутся только из окружения; до запуска подтвердите маршрут, model ID и параметры в текущем каталоге RussiaAPI.

const events = new Map();

export function appendVideoEvent({ operationId, type, taskId, inputVersion }) {
  const chain = events.get(operationId) ?? [];
  if (chain.some((item) => item.type === type && item.taskId === taskId)) return { state: 'duplicate_event' };
  chain.push({ type, taskId, inputVersion, occurredAt: new Date().toISOString() });
  events.set(operationId, chain);
  return { state: 'recorded' };
}
// Store a RussiaAPI key only in server environment variables; do not log requests or credentials.

Проверьте синтаксис, добавьте аутентификацию своего маршрута и негативные тесты. Не логируйте тело запроса или заголовки только ради отладки.