Port is already in use when using @SpringBootTest with a separate management port and a mock web environment

[jimshowalter]

We didn't change anything in our code or configuration, other than upgrading versions.

We can run the service locally, and can run the tests individually. But when we try to run the tests together, we get the port error.

We were already on Spring 6.1.0 and Spring Boot 3.1.5, so this should have been a small upgrade.

We're using the latest version of JUnit, and are not running the tests in parallel.

The tests fail with the port error whether virtual threads are enabled or disabled.

Is there some new cleanup/finalization we need to add? We looked at the release notes for both Spring and Spring Boot and didn't see anything relevant.

[yanivnahoum]

Seeing the same thing. Not sure if in @jimshowalter 's configuration 8090 is the value of management.server.port, but in my case, when I assign a value to management.server.port, a few @SpringBootTests start failing with "Port xxxx is already in use", where xxxx is the value of management.server.port

[wilkinsona]

I'm not aware of anything that would have changed the behavior here. Perhaps #38502, but that's little more than a guess at this point.

If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

[jimshowalter]

8090 is the management.server.port we use in tests. If we change management.server.port to some other port, we get the same error.

[jimshowalter]

You're asking us to try to cut a huge pile of intellectual property down to a reproducible test case, but we know something in the latest Spring or Spring Boot causes this, and you're way more famliar with that codebase than we are.

This will block many developers from using virtual threads. Can you please fix this problem?

[wilkinsona]

we know something in the latest Spring or Spring Boot causes this, and you're way more famliar with that codebase than we are

We know that a combination of something in your codebase and something in the latest Spring or Spring Boot causes this. We know nothing about your codebase and you know something about ours. It's very helpful if someone who's familiar with both sides of the problem spends some time creating a minimal reproducer.

Can you please fix this problem?

We were not refusing to fix it, far from it, just looking for some assistance in addressing the problem that you've reported.

I have now managed to reproduce the problem and, as guessed above, #38502 is the cause unfortunately. A (far from ideal) partial workaround is to use @DirtiesContext to prevent caching of test contexts.

[jimshowalter]

That was fast!

Do you have a sense for when the next release will be published?

[jimshowalter]

"We know that a combination of something in your codebase and something in the latest Spring or Spring Boot causes this. We know nothing about your codebase and you know something about ours. It's very helpful if someone who's familiar with both sides of the problem spends some time creating a minimal reproducer."

That's a very fair point. Unfortunately, our codebase is massive, and every time we try to reduce it to a reproducible example, we fail.