Каковы настройки повтора для подписчика в pubsub и как их правильно установить в весеннем приложении?

У меня есть служба spring, подписывающаяся на сообщения из темы в pubsub облака google (вытягивание). В целом работает корректно. Но я хочу иметь больше контроля над недавними сообщениями. Моему сервису иногда нужно удалить сообщение или просто пропустить ackDeadline, чтобы я снова получил сообщение позже. При тестировании с одиночными сообщениями неподтвержденные сообщения возвращаются ко мне почти мгновенно, а те, которые я не подтверждаю или вообще не подтверждаю, возвращаются через 10 секунд по умолчанию для ackDeadline. Я хотел бы отложить повторное потребление этих сообщений. Я думал, что настройка повтора предназначена для таких случаев. Я также должен упомянуть, что в настоящее время я тестирую локально с помощью эмулятора и создаю подписку из кода. Я использую PubSubAdmin для управления.

В соответствии с этим документ я попытался установить эту конфигурацию в моей конфигурации профиля. нравится:

spring.cloud.gcp.pubsub.subscriber.retry.initial-retry-delay-second: 4
spring.cloud.gcp.pubsub.subscriber.retry.max-attempts: 5
spring.cloud.gcp.pubsub.subscriber.retry.initial-rpc-timeout-seconds: 4
spring.cloud.gcp.pubsub.subscriber.retry.max-rpc-timeout-seconds: 8
spring.cloud.gcp.pubsub.subscriber.retry.max-retry-delay-seconds: 7
spring.cloud.gcp.pubsub.subscriber.retry.total-timeout-seconds: 3000

но это не повлияло на время повторного появления сообщений. Я неправильно понимаю смысл повторных настроек? может быть, они вступают в силу только в том случае, если есть какие-то проблемы с подключением, но не в случаях взлома или отсутствия подтверждения? Или мне нужно установить параметр при использовании deployManager для создания подписок, и мне не разрешено устанавливать их из кода? Или, может быть, установка их в конфигурациях профиля (разработки) не будет работать с PubSubAdmin? Спасибо за любые предложения!

изменить: я хочу, чтобы первая повторная попытка произошла через 5 секунд, а следующая повторная попытка - через 10 секунд и т. д. Кроме того, я хочу установить максимальное число повторных попыток. Так что меня не интересует установка ackDeadline просто на большее число.

edit2: почему nacking: одна из служб (назовем это мостом) подписывается на сообщения, должна проверять каждое сообщение и, если все в порядке, передавать его другой внешней системе. эта служба действует как мост для этой системы, так как мы не можем работать со второй системой напрямую. в некоторых случаях сообщению нужна дополнительная информация, поэтому мост попытается получить ее где-то еще (включено много микросервисов), и иногда бывает, что в данный момент времени дополнительной информации там нет (пока). Итак, первая идея заключалась в том, чтобы не подтверждать сообщение и позволить ему прийти позже. но я не хочу спрашивать каждые 10 секунд в течение следующих 7 дней (с ackDeadline), я хочу просто попробовать несколько раз, и если его не будет через 2 часа, он никогда не придет. поэтому мы попытались отказаться и надеялись, что эти настройки повторной попытки помогут управлять повторной отправкой. Но поскольку они этого не делают, я полагаю, что единственный выход — создать что-то для управления этими сообщениями в мосте самостоятельно. Может быть, хранить идентификаторы сообщений и количество повторных попыток, чтобы я мог подтвердить, например, 5 раз и отправить сообщение в другую тему, чтобы по-другому с ним справиться. Или известны лучшие решения?