А за пределами дебага/тестирования, в рамках эксплуатации вам доводилось эти

параметры изменять?

да, любой сбой требующий переобработки данных и быстрее поменять групид чем ресетить его

Да, ну вот такой кейс я выше описал тоже. А почему быстрее чем ресет? Там какие-то дополнительные подводные камни помимо --reset-offsets?

потому что смена конфига это обновить параметр, а ресет это нужен доступ к кафке, чего как раз у вас вообще невозможно организовать

Не, возможно, просто надо для этого цепляться к EC2/ESC напрямую, все за контуром же. Просто если такое плохое зло случилось - это звучит как прямо очень исключительный кейс, для этого должна например вся БД монументально вылететь, что в облаках сложно представить, это прям Р0 инцидент.

вот вы и описали чем смена параметра лучше) и как ни странно более контрлируемая, т.к. пока вы делаете ресет нужно чтобы консумер лежал, а это доп телодвижения дождаться пока остановится, ресетнуть, запустить

Но увы позволит только либо все прочитать, либо ничего. Ресетом можно до даты например доресетить. Но да, если надо полностью прочесать топик, то звучит будто конфиг CG удобнее. А имя топика?

с топиками было такое - у вас топик не соответствует названию который мы тут в сопровождении кафки придумали, замените

У нас например есть dlq топики. Редко но бывает, что мессаджи улетают туда. Тогда после ресерчей и фиксов запускается инстанс сервиса, который вычитывает с этого топика.

Если такое допустимо, то конечно. У нас длку вычитается сразу же в инбокс, и переобработка в рамках того же консюмера уберчувствительная операция. Но да, тоже вариант юзкейса, спасибо!