Feature request: max-test-threads

[aslilac]

Motivation

we have a slightly unusual development environment at my work. we all work in sysbox "system containers" on an enormous server with way too much ram and a 128 core processor.

on a new project at said work, we've been using rust, sqlx, and postgres. it has a lot of #[sqlx::test] tests, in which sqlx spins up a single shared postgres instance for all of the tests to use, but gives each it's own db with all migrations applied within the instance. all of these tests then try to connect to that instance. when running these tests using nextest the default parallelism of num-cpus (128 in my case) overwhelms postgres' default connection limit of 100, causing some tests to fail, saying they're unable to connect.

Proposal

I don't wanna have to use a profile that sets test-threads = 100 because obviously not all computers (like our ci runners, which are entirely more normal) have 100+ cores, and I think num-cpus is generally the much more sane default here. but I would love a way to say either...

• set a maximum level of parallelism, rather than an exact level (max-test-threads = 100)
• a way to give #[sqlx::test] slightly special treatment, and only apply max-test-threads to that group of tests, allowing other non-sqlx tests to still run while the sqlx pool is theoretically fully saturated.

Alternatives

No response

Additional context

No response

[aslilac]

in case someone else happens to stumble here before this gets a real solution, my workaround for now is to always run nextest through a Justfile when working locally, and invokes it as:

cargo nextest run -j$(node -e "console.log(Math.min(64, require('os').availableParallelism))")

you could do the exact same trick in a Makefile or mise script or whatever have you as long as node is around