Concurrent sessions.create calls can leak an orphaned browser process

Have you checked our README?

• I have checked the README

Have you followed our Troubleshooting?

• I have followed your Troubleshooting

Is there already an issue for your problem?

• I have checked older issues, open and closed

Have you checked the discussions?

• I have read the Discussions

Have you ACTUALLY checked all these?

YES

Environment

- FlareSolverr version: master at 0f05ed8fc974b215c36892b5a30122e27fe3c671
- Last working FlareSolverr version: unknown
- Operating system: Windows 11 (unit-level reproducer)
- Are you using Docker: no
- FlareSolverr User-Agent (see log traces or / endpoint): not applicable
- Are you using a VPN: no
- Are you using a Proxy: no
- URL to test this issue: any target, with simultaneous sessions.create requests using the same session ID

Description

Description

SessionsStorage is shared across Waitress threads but checks and creates session IDs without a common lock. Two simultaneous sessions.create calls for the same ID can both observe that the ID is absent, both launch a WebDriver, and then overwrite the entry with one driver. The other browser process becomes unreachable and cannot be destroyed by the normal session flow.

Expected behaviour

At most one WebDriver should be created for each session ID, including under concurrent requests.

Proposed fix

Guard storage creation, lookup, replacement, destruction, and enumeration with a re-entrant lock. A deterministic regression test starts two threads against the same ID and asserts that the factory runs once.

Logged Error Messages

No external server error is required; the race is reproduced with a deterministic unit-level concurrent factory test.

Screenshots

No response