When testing for absence of specific race conditions (of whatever kind), I would try to eliminate the "race" part and instead slow everything into discretes steps that then get permuted. This makes the test casses reproducible, but isn't as easy as it sounds because you need to restructure your code so the racing parts become separately callable steps.

If I assume the following structure (and error /race situation):

1. User logs in on /login
2. Session gets marked as "logged in" and the user account gets added to the session in the database
3. User/session-specific CSS gets requested from /user/css
4. User/session-specific CSS gets generated according to the session information from the database

... then, with the knowledge that we have a race condition, it's not hard to imagine the race happening somewhere between steps 2 and 4.

To reproduce the error, it will be convenient to be able to permute these steps for the tests, so these steps should be callable somehow.

Ideally, we don't need to stuff a session into the database just to retrieve it again, so I'd like to be able to optionally pass premade session information into the CSS generation. This should allow us to test whether stale information in the session generates correct CSS, at least in the case where we cannot control how quickly the database gets written to.

Alternatively, an invariant to test for would be that the session has always been updated with the correct user before any HTML is output to the client. To make that possible, you will need to have separation between HTML output and session flushing so you can put your check there.

Maybe you have more information about the race condition, then maybe we can suggest other approaches on where to cut the HTML generation, session updating and sending of the response...