Wpis z mikrobloga

Siema Mirasy.

Potrzebuje, aby ktoś koncepcyjnie potwierdził lub zaprzeczył, czy taki prosty scenariusz jest wykonalny:

1) Mam lambdę (kotlin/quarkus)
2) Lambda nasł#!$%@? na SQSEvent
3) Potrzebuje napisać test integracyjny, który odpali mi logikę lambdy i który sprawdzi, czy zfailowane wiadomości podczas ich przetwarzania polecą na DLQ
4) Lambda zwraca typ SQSBatchResponse i póki co na sztywno failuje wiadomości

Czy koncepcyjnie jest to w ogóle wykonalne? Quarkus ma wbudowanego LocalStacka i nie widzę, aby stawiał jakiekolwiek kolejki SQS podczas wykonywania testów samej logiki. Ma to chyba sens, bo w końcu dostaje sam typ SQSEvent, a więc kolejki w zasadzie nie są mu do niczego potrzebne.

Czy dobrze rozumiem, że schemat całego SQS - Lambda - DLQ wygląda tak:
ktoś wysyła wiadomość na SQS -> lambda ma trigger na SQSEvent, więc odczytuje rekordy -> jeden z rekordów nie zostaje poprawnie przetworzony, więc leci exception -> zfailowany rekord tworzy np. SQSBatchResponse.BatchItemFailure() -> lambda zwraca List<SQSBatchResponse.BatchItemFailure> -> (i to co mnie teraz interesuje) AWS w zależności od konfiguracji sam reaguje na te faile i sam wrzuca je na DLQ bez ingerencji już samej lambdy (co zaprzeczałoby w sumie mojej koncepcji testu integracyjnego)?

Być może jest jakaś opcja, żeby w teście IT wysłać wiadomość przez SQSClienta i żeby lambda się jakoś striggerowała na niego, hmm?

Dzięki z góry za odpowiedzi!

#programowanie #java #aws #lambda #quarkus #sqs #localstack
  • 1
@Yeboy wiadomości idą na dlq jeśli w czasie visibility timeout nie zostały usunięte z głównej kolejki. Dla aws nie ma znaczenia czym to czytasz i jak przetwarzasz. Jeśli nie usuniesz to idzie to dlq jeśli masz redrive policy