However, it does not guarantee only once delivery when used as a Lambda trigger.

https://aws.amazon.com/ru/blogs/compute/new-for-aws-lambda-sqs-fifo-as-an-event-source/

И ещё
https://stackoverflow.com/questions/64428146/aws-lambda-triggered-twice-for-a-sigle-sqs-message

ну походу да, надо писать внешний трекер в какойто базе https://stackoverflow.com/questions/62364409/sqs-fifo-queues-not-ensuring-single-time-delivery-when-used-as-lambda-trigger

либо душить concurrency

либо увеличивать visibility timeout

Я посчитал, что возможна двойная доставка одного и того же события с набором сообщений. Поскольку это FIFO, то каждое сообщение имеет group id, и в одном событии может быть набор сообщений с разными group id. Стало быть, можно собрать уникальные group id, отсортировать и составить в ключ, по которому и делается блокировка. Свойства FIFO гарантируют, что group id не будет обработан параллельно

Ответил, но вопрос про исключение открытый.

Visibility timeout у меня 18 минут, таймаут лямбды 15

если у тебя самописный сторонний лок - то я считаю что во "втором треде" надо бросать эксепшен, а в "первом треде" после релиза лока делать руками "delete" из sqs

Да, руками я удаляю

а через что сделан лок, кстати?

может проще не блокировку а просто хранитьпослежнее обработаное событие, у него же наверняка есть чтонить уникальное аля timestamp с точностью хорошей? тогда просто выбрасывать из пачки все уже обработанные и более железобетонно даже если размер пачки поменяется каким то образом, дедупликация сработает как надо

так там батчи параллельно могут запуститься, первый закончит позже второго

Часть из пачки внутри одного group id может быть обработана и удалена, а часть -  нет. То есть, таймштамп последнего обработанного тут неприменим, тут не массив с конца откусывают, а дырки в нём делают.

я походу стар для этого дерьма, я больше работать люблю )

Я вокруг этих распределённых вещей уже месяца два хожу (именно с FIFO, так-то дольше), и самое неприятное, что непонятно, как это надёжно делать и проверять.

Добрался до https://verdi.uwplse.org, но что-то я сомневаюсь, что оно массово применяется. Понятно, что в самом Амазоне до использования TLA+ дошли, но где Амазон, и где остальные.

если ктото юзает SQL Server - смотрите какой прикольный хак
https://news.ycombinator.com/item?id=27153232

> Если из обработчика в лямбде (в С#) выбросить исключение, то это будет воспринято (кем?), как просьба ещё раз отправить эти же сообщения, эту пачку, за исключением тех, что были явно удалены в ходе выполнения кода лямбды. Если же исключения не было, то сообщения будут удалены (кем?)

Все зависит от retry policy (aka visibility timeout в мире sqs) + redrive policy (aka конфигурации dead-letter queue). Но это все детали реализации SQS о которых консьюмер вообще ничего не должен знать. Так же как консьюмер не должен ничего знать о существовании других консьюмеров.

Задача консьюмера принять сообщение, сделать dedup и выполнить работу. Если вдруг нужны distributed locks (а если у вас очереди, то они не нужны т.к. есть более подходящие инструменты), то лучше  попытаться поставить лок и в случае, если лок уже стоит, вместо exception имеет смысл вернуть сообщение руками в конец очереди:
if !aquitedLock { enqueueMessage(); return } if dedup ( return }

Или использовать FIFO queues  (и там миллион своих приколов)

> Я не могу найти ответа в документации AWS.
https://docs.aws.amazon.com/lambda/latest/operatorguide/sqs-retries.html

sqs очереди имеют семантику at-least-once delivery

Amazon SQS stores copies of your messages on multiple servers for redundancy and high availability. On rare occasions, one of the servers that stores a copy of a message might be unavailable when you receive or delete a message.

If this occurs, the copy of the message isn't deleted on that unavailable server, and you might get that message copy again when you receive messages. Design your applications to be idempotent (they should not be affected adversely when processing the same message more than once).

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

Поймать исключение в лямбде и перекинуть сообщение в dead letter queue