Assert queues are all the same type in setQueueNames so applications …

[internetstaff]

…fail to start rather than throwing endless Executor errors.

:loudspeaker: Type of change

• [ ] Bugfix
• [ ] New feature
• [ ] Enhancement
• [x] Refactoring

:scroll: Description

This asserts there's not a mix of FIFO and non-FIFO queues earlier in SqsMessageListenerContainer.setQueueNames instead of waiting for the container to fail on startup.

:bulb: Motivation and Context

Migrating from 2.x, we had an @SqsListener with a mix of queue types. Instead of failing at startup, there's only one line logged:

s.c.a.AnnotationConfigApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.context.ApplicationContextException: Failed to start bean 'io.awspring.cloud.messaging.internalEndpointRegistryBeanName'

... followed by an endless loop of AWS SDK executor not accepting a task errors from all queues.

This is probably not an ideal fix - it seems like any failure in io.awspring.cloud.sqs.listener.DefaultListenerContainerRegistry#start should be fatal rather than leaving queues in a weird half-started state. I didn't go that deeply. Feel free to chuck this for a wider fix. :)

:green_heart: How did you test it?

Added a simple UT, then pulled the SNAPSHOT into the application with the issue. Verified the app failed immediately with a very clear error.

:pencil: Checklist

• [ ] I reviewed submitted code
• [x] I added tests to verify changes
• [ ] I updated reference documentation to reflect the change
• [ ] All tests passing
• [x] No breaking changes

:crystal_ball: Next steps

[tomazfernandes]

Hi @internetstaff, sorry for the long delay. Your proposal sounds reasonable.

it seems like any failure in io.awspring.cloud.sqs.listener.DefaultListenerContainerRegistry#start should be fatal

I'm not sure I follow - as far as I'm aware if a container throws at startup, the app won't start up. So with the change you're proposing I believe it should prevent the app from starting up? What am I missing?

Thanks.

[internetstaff]

I'm not sure I follow - as far as I'm aware if a container throws at startup, the app won't start up. So with the change you're proposing I believe it should prevent the app from starting up? What am I missing?

Sorry for the delay - I had to fire this back up myself. :)

What I see with this condition is that I do get "Application run failed" but the application doesn't shut down. Instead, it stays in a zombie state.

With this change, it logs the error and shuts down.