Selenium WebDriver and Browser Driver Session Cleanup on Client Process Termination

Session Management Interoperability Between Selenium WebDriver and Browser Drivers

Selenium WebDriver communicates with browser-specific drivers like ChromeDriver and GeckoDriver through the W3C WebDriver Protocol over HTTP. The WebDriver.quit() method is designed to close all associated windows and terminate the driver process, while WebDriver.close() only closes the current window without ending the session.

Research indicates an unresolved behavior regarding the consistency of session cleanup when the client process crashes before sending the delete session command. The WebDriver specification defines DELETE /session/{sessionID} as the mechanism for cleanup, but this relies on the client properly invoking quit() or the JVM shutting down gracefully.

When client processes terminate unexpectedly—due to crashes, SIGKILL signals, or abrupt container shutdowns—the HTTP connection to the driver is severed without the delete session command being sent. This raises questions about whether browser drivers reliably detect and handle these abrupt disconnections, and whether they properly release allocated resources like ports, memory, and subprocess handles.

The W3C WebDriver specification does not explicitly define driver behavior in these scenarios, leaving implementation-specific handling that may lead to orphaned processes or resource exhaustion over time.

Key questions:

• How do ChromeDriver and GeckoDriver differ in their detection and handling of abruptly terminated client connections?
• What mechanisms, if any, exist on the driver side to detect and clean up sessions when the client process disappears without sending a delete request?
• Can connection pool exhaustion in Selenium Grid environments be reliably diagnosed and prevented when client-side crashes occur?