loadtest

Overview ¶

Command loadtest exercises the control plane concurrently and checks that row-level security holds while it does (WP-I3).

The interesting risk is not throughput, it is IDENTITY LEAKING BETWEEN REQUESTS. authz.WithUser sets workgraph.user_id with is_local = true, so it is scoped to the transaction and released when the transaction ends. That is the correct choice, and it is exactly the kind of correct choice that is worth proving rather than asserting: a connection pool hands the same physical connection to different users in succession, and if the setting were session scoped instead, user B would inherit user A's identity and read their projects. The bug would be invisible under serial testing and catastrophic under load.

So the pool is deliberately SMALLER than the number of concurrent users. With 25 users and 5 connections, every connection is reused across identities many times per second, which is the condition the bug needs.

Each worker's expected project set is computed once, serially, before the concurrent phase. Comparing against a precomputed expectation is what makes this a real test: if a worker asked "which projects am I a member of" during the concurrent phase and identity had leaked, the membership answer would leak in the same direction and agree with itself.

Run ON the control node, against the load database:

loadtest -dsn "postgres://workgraph_app:PW@127.0.0.1:5432/workgraph_load?sslmode=disable" \
         -users 25 -conns 5 -seconds 60