One viewer account, twelve read-only scenarios, and the suite behaves as if -w 1
Asked 5,830 views3 answers
22votes
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.