Confluence 8.0 request timeout transition and async indexing cleanup boundary

Confluence 8.0 introduced the system property confluence.request.timeout.seconds (default 300) to cap how long Tomcat keeps an HTTP request open before returning a 504 Gateway Timeout. When that timeout fires, the HTTP thread is aborted, but asynchronous tasks spawned by the request—such as content indexing or search reindex—are not automatically interrupted. As of Confluence 8.5.x, it remains an open question whether the server propagates InterruptedException to plugin-provided Callable tasks submitted via SpringTaskExecutor; current behavior appears to swallow the interrupt flag, though this warrants verification against the latest source.

This creates a compatibility boundary between the HTTP request lifecycle and background executor cleanup. REST clients can detect a 504 response and retry, but there is no guaranteed cleanup of server-side resources, leading to possible thread-pool leakage under high load when the searchIndexing executor retains active threads.

Does Confluence 8.5.x propagate interrupt signals to plugin-provided Callable tasks submitted via SpringTaskExecutor when confluence.request.timeout.seconds expires? What is the documented behavior for the searchIndexing executor's thread pool after a client receives a 504 Gateway Timeout? Are there version-specific compatibility notes for adjusting confluence.request.timeout.seconds alongside confluence.indexing.thread.pool.size?