Which cleanup mechanisms apply when a Drupal Ajax request is aborted?

When a browser aborts a Drupal Ajax request, the client-side connection closes, but the server-side PHP process continues executing until it naturally completes, reaches the max_execution_time, or explicitly detects the disconnection. Drupal core does not provide a dedicated hook for aborted Ajax requests.

Confirmed Behavior

• Process Persistence: PHP does not automatically kill a script just because the client disconnected; the script continues to run in the background.
• Event Execution: Symfony's kernel.terminate event typically fires after the response is sent, including cases where the connection was aborted, provided the PHP process is allowed to finish.
• Core Patterns: While standard Ajax callbacks lack abort detection, Drupal's Batch API and Queue workers utilize connection_aborted() to stop processing during long loops.

Recommended Cleanup Strategy

Because no single event is guaranteed across all server configurations, a dual-layered approach is necessary for releasing locks or deleting temporary files.

1. Active Detection (Inside the Callback)

For long-running processes, manually check the connection status. This prevents the server from wasting resources on a request the user has already abandoned.

if (connection_aborted()) {
  // Perform immediate cleanup and exit
  return [];
}

2. Passive Cleanup (Post-Response)

Use a kernel.terminate listener or a PHP shutdown function to ensure cleanup occurs regardless of how the script ended (unless the process was killed by the OS/SIGKILL).

Example: Symfony Event Subscriber

public function onKernelTerminate(PostResponseEvent $event) {
  if (connection_aborted()) {
    // Release locks or remove temporary data
  }
}

Environmental Uncertainties

The reliability of kernel.terminate and connection_aborted() depends heavily on the infrastructure:

• Reverse Proxies/Load Balancers: If a proxy (like Nginx or Varnish) buffers the response, PHP may believe the connection is still open even if the browser has disconnected.
• FastCGI: The use of fastcgi_finish_request() can alter when the connection is considered "closed" relative to the script's execution.

Verification: To verify behavior in your specific environment, add error_log() entries to both a kernel.terminate listener and a register_shutdown_function(), then abort a request via Browser DevTools to see which logs persist.

Diagnostic Detail Required: Does your environment use a buffering reverse proxy or fastcgi_finish_request()? This determines if you can rely on post-response events or must prioritize active polling.