We encountered an issue where our custom test execution listener, responsible for cleaning the database after-test, was executed after the ApplicationContext was cleaned up.
The custom listener had the order3000 to prevent conflicts with other internal listeners.
However, we didn't know that DirtiesContextTestExecutionListener has the same order (3000, what a coincidence), leading our cleanup listener to run after the context was marked dirty.
This behavior led to unexpected results - Spring initiated a new context since the previous one was removed, resulting in the database being cleaned for another test.
It would be great to understand the rationale behind order 3000 for DirtiesContextTestExecutionListener.
Looks like the logic should be more complex: after method marking should be executed the last (having listener with the lowest order value) before method marking should be executed the first (listener with the highest order value).
Spring Version: 6.1.13
Comment From: snicoll
No idea why this was reported twice. Duplicate #34225
Comment From: tfactor2
I got a session expired, but apparently, github managed to create a ticket - didn't notice that. Thanks