One viewer account, twelve read-only scenarios, and the suite behaves as if -w 1
Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
A partner gives us exactly one viewer account and will not create more — it is their system, their policy, and no amount of asking has moved it.
Twelve scenarios carry @user:viewer. Every one of them only reads: open a report, assert some numbers, leave. With -w 4 one worker gets the account and the other three wait and then fail on the lease.
So the suite runs at one worker's pace for the viewer scenarios and I cannot fix it by adding accounts, because there are no accounts to add. Is serialising them into their own run with -w 1 the only shape available?
Exclusive leasing is the default because two workers on one identity see each other's writes, and that turns a passing suite into an intermittently failing one that looks like an application bug. For a read-only suite that reasoning does not apply, and the cost of applying it anyway is exactly what you are seeing: eleven scenarios queueing behind one lease and then timing out.
yaml
data:
userPool:
dataset: users
roleColumn: role
mode: shared
A shared pool hands out an account without taking a lease at all. The choice is deterministic by worker index, so workers get different accounts when the pool has them and the same one when it does not — which is the point. Nothing to release, nothing to time out.
Two caveats worth being precise about:
mode is a property of the pool, not of a role. If any scenario anywhere mutates user-scoped state, do not flip the whole thing. The safe shape is a pool of genuinely read-only accounts, and separate accounts for the scenarios that write.
If you would rather queue than share, data.userPool.waitMs sets how long a worker waits for a free account before failing. Thirty seconds by default, which is why your failures arrive in a batch after a pause.
We landed somewhere between the two. The read-only scenarios use a shared pool. The four that write live in their own module and run separately, which also means a failure there does not need triaging against "did another worker do this".
Splitting by what the scenario does to the account turned out to be a better line than splitting by role.
Slightly meta, but the USER_POOL_EXHAUSTED hint spells out the options in order — shared mode first, then more accounts, then the wait, then fewer workers — and it names the poolSize trap at the end. It is a long hint and easy to skim past when you are annoyed. Reading it would have saved me an afternoon.