Kafka consumer с manual commit

Примеры3B · Общие setup/версии · Фактические проверки (архив рабочего проекта)

Тип материала: учебное практическое упражнение. Выполненные и непроверенные шаги указаны отдельно.

Команды выполняются из examples/processing после общего setup; $labPython — interpreter venv. Runtime и documented expected result различаются.

Зависимости и версии

Kafka4.1/client2.12, SQLite atomic inbox+totals. projection.py, consumer.py. Свежий consumer group и topic c исходными пятью records.

Команды запуска

& $labPython kafka_consumer.py --group handbook-manual-v1 --database output/manual.sqlite --max-records 5 --crash-after-effect
# Первый запуск намеренно завершается ошибкой после DB effect, до offset commit.
& $labPython kafka_consumer.py --group handbook-manual-v1 --database output/manual.sqlite --max-records 5

Тестовые данные

e1/e2/e3/e1/e4; exact minor integers, identity=(tenant,event_id), canonical payload hash. Для независимого запуска выбирайте новый group/database, сохраняя original event IDs.

Ожидаемый результат

После replay totals остаются275/50, inbox содержит4 identities. Синхронный commit(message=...) выполняется после effect/quarantine. Consumer сверяет ответ с запрошенным next offset и проверяет ошибку каждой partition. При общем исключении, частичной ошибке или неполном ответе consumer завершает работу без итогового подтверждения. При повторном чтении локальная проекция использует прежнюю бизнес-идентичность события. Локальные duplicate/conflict/rollback/reopen paths реально проверены отдельным QA; network crash/rebalance ещё нет.

Ограничения и статус проверки

Одна запись обрабатывается за раз, поэтому нет скрытого commit beyond unfinished prefix. SQLite — reporting projection, не ledger. Cleanup inbox ограничивает dedup horizon. --crash-after-effect — controlled exception, не power-loss/failover test.

Полный журнал ограничений (архив рабочего проекта) хранит NOT_RUN и failed runtime attempts; их нельзя считать выполненными integration tests.