в методтейбле точно нет

в метод тейбле хранится информация о mark GC

вот и я подумал, что оно там не должно затирать

не работал с брайтером, но раббит, если включены подтверждения получения, а это, думаю, ваш случай, вернет все неподтвержденные сообщения в очередь, если клиент упадет. Т.е. в вашем случае при падении хэндлера надо убедиться, чтобы падал channel или подключение. Если падает только ваш код, то достаточно завернуть в try-catch и написать логику повтора. С другой стороны, если вы не можете обработать сообщение, то возвращать сообщение в очередь смысла мало, т.к. вы его после этого снова получите.
Позвольте встречный вопрос, почему вы используете brighter?

Я пришёл на проект недавно и он тут был до меня

А если раббит упадёт то вернет фигу :}

Вообще, я сам бы взял медиатр

Но там нет поддержки распределённой очереди из коробки, емнип

Еще один кейс для распределенного лока)

кстати по итогу скорее всего приду к хенгфаеру ибо пока не могу понять как через распределённый лок сделать так, чтобы если джоба была запущена по расписанию,сделать так, что после того как лок её отпустил(выполнилась) другие инстансы не начали её тоже выполнять

Ну пишешь в джобе иф получил лок то выполняем, элз ретурн

хмм..

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

Да, это хэнгфаер и делает

Хранит пул задач

Но хэнгфаер не будет делать ограничений на инстансы

Если даже объявишь ReccuringJob то можно её запускать в куче экземпляров одновременно

А так он балансирует задачи по инстансам, да

Но если задачку запустишь два раза (например клиент заретраит) то будет одновременно на разных инстансах выполняться

Тут уже можно и распредлок заюзать если нельзя одновременно