Mysqli test cases using fake_server are flaky

[cmb69]

Description

I've just stumbled upon https://github.com/php/php-src/actions/runs/11942808872/job/33290600427. The test uses port 50001 which is otherwise not explicitly used by the php-src test suite, but might be used by a test using an ephemeral port. I'm not sure, though, that a port collision is the cause of the test failure.

However, the other regression test for that issue all use port 33305 (which is also the default of the fake server); this is prone to collisions when running tests in parallel.

I think it's best to use ephemeral ports everywhere (see #6132).

PHP Version

PHP-8.4 (likely 8.1 - master)

Operating System

Windows (likely POSIX as well)

[cmb69]

Oh, just noticed that the mysqli test suite is marked as conflicting (mysql) anyway. So it's certainly not that bad. Still, there seems to be room for improvement, and at least the actual test failure mentioned above should be sorted out, ideally.

[cmb69]

Happened again; this time on Linux.

[bukka]

Yeah that 50001 seems somehow problematic for some reason. I changed to be 33305 like others in 51f5539 .

I don't think we should be ever running mysqli ones in parallel. Although we could maybe run the fake ones but they are are quite quick and there might be loads of them so it would require some automatic port allocation. Maybe something for later.

Anyway let's see if that port change helps.

[bukka]

Oh I could actually change it to empheral. But still I would have to look to some exception how to run just those in parallel...

[cmb69]

But still I would have to look to some exception how to run just those in parallel...

Does the CONFLICTS file work only for the directory it's in, or also for all subdirectories? If the former, the tests could be moved to their own subdirectory.

[cmb69]

Yeah that 50001 seems somehow problematic for some reason. I changed to be 33305 like others in 51f5539 .

Hmm, apparently that did not solve the issue. Is there maybe a timing issue?

[bukka]

hmm strange, maybe the connection is somehow kept open but that doesn't explain why it was happening only 50001 which shouldn't be used elsewhere. I will think about some way how to ideally pick up or fallback to some free port.

[cmb69]

Probably fixed via 39c292b.

[bukka]

Seems like the issue no longer there so closing.