2.3 KiB
Классификация застряла на 68/84: диагностика 2026-08-27
Наблюдение
На экране классификация остаётся на 68/84, хотя контейнер продолжает работать.
Проверка через ВМ:
GET /api/batch-progress?batch=acbdffe5-e3ec-43f4-ab61-84861cac35bd
{"counts":{"classified":68,"garbage":16},"ok":true,"total":84}
Повторный запрос вернул то же значение. Kubernetes показывает pod
pythonk8s-574b5cf9b4-z4wxz в состоянии Running, Ready 1/1, RESTARTS 0.
Событий Kubernetes нет. На ВМ contracts.service активен, convert_server.py
запущен в одном экземпляре.
Причина в коде
site/routes/api_bp.py возвращает раздельные счётчики classified, failed и
garbage, а total равен числу всех документов батча.
site/static/app.js в runClassify() считает завершённые документы так:
var done = (d.counts.classified || 0) + (d.counts.failed || 0);
garbage в эту сумму не включён. Для текущего батча:
done = 68 classified + 0 failed = 68
total = 84
garbage = 16
фактически завершено = 68 + 0 + 16 = 84
Поэтому условие done >= total никогда не выполняется, polling не
останавливается, а кнопка остаётся на 68/84. Это ошибка фронтендового
подсчёта прогресса, а не зависание Kubernetes или LLM на 68-м файле.
Исправление
В site/static/app.js к числу завершённых документов добавлен конечный статус
garbage:
var done = (d.counts.classified || 0)
+ (d.counts.failed || 0)
+ (d.counts.garbage || 0);
Версия приложения повышена с 2.0.17 до 2.0.18; cache-buster статических
скриптов обновлён в site/templates/index.html.
Kubernetes проверялся только командами чтения через ВМ:
kubectl get, kubectl describe, kubectl top, kubectl logs.