TypeScript Language Service concurrency limit during bulk refactoring operations

Missing throttle for TSServer compilation requests

WebStorm delegates TypeScript diagnostics to the TypeScript Language Service (TSServer) when Use TypeScript Language Service is enabled. During multi-file refactorings that touch hundreds of files, the IDE spawns unbounded compilation requests to the TSServer process, which can saturate CPU and block the UI thread for extended periods.

Constraints and uncertainty

• No documented upper bound on concurrent compilation requests triggered by rapid file changes.
• JetBrains documentation mentions Recompile on changes but does not specify a throttle, queue depth, or back-pressure mechanism.
• Disabling the language service falls back to WebStorm's built-in analyzer, losing incremental type-checking benefits.
• No official configuration exists to limit TSServer worker threads or prioritize UI responsiveness over diagnostic freshness.

Questions

1. Is there an undocumented registry key or idea.properties setting that caps concurrent TSServer requests or introduces a request queue?
2. Can the Recompile on changes behavior be tuned to batch or debounce file-change notifications before they reach TSServer?
3. Does the TSServer protocol itself expose a flow-control mechanism that WebStorm could leverage but currently does not?