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

[internetstaff]

…fail to start rather than throwing endless Executor errors.

📢 Type of change

• Bugfix
• New feature
• Enhancement
• Refactoring

📜 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.

💡 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. :)

💚 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.

📝 Checklist

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

🔮 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.

[tomazfernandes]

I don't think we need to check this in two places, how about we only check it here on setQueueNames and do that before calling super?

[internetstaff]

Done, and confirmed this still resolves the issue for me.

[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.