Editor Services Host 100% CPU spin when app.json has empty dependencies array (Linux)

[Brad-Fullwood]

Editor Services Host 100% CPU spin on Linux (Two Issues)

Summary

On Linux, the AL Language Server's Microsoft.Dynamics.Nav.EditorServices.Host process has two 100% CPU spin issues:

Issue 1: Deployment Delay (Empty Dependencies)

When app.json contains an empty dependencies array ("dependencies": []), the process consumes 100% CPU for approximately 5 minutes during publish/debug initialization before any API requests are made.

Workaround: Adding any dependency (e.g., System Application) immediately resolves this issue.

Issue 2: Breakpoint Handling Freeze (No Known Workaround)

Even with dependencies present, hitting a breakpoint causes the debugger process to spin at ~85-100% CPU. The editor shows "paused on step" in the call stack, but:

• Variables do not populate
• Source code location is not displayed
• Step controls (continue, step over, etc.) are unresponsive
• Business Central session freezes

The DebuggerServices.log shows SignalR connection established successfully, but no further log entries are written despite the process consuming 85%+ CPU for 5+ minutes.

Environment

• OS: Linux (Arch Linux 6.17.9-arch1-1, but likely affects all Linux distributions)
• Editor: VS Code / Cursor
• AL Language Extension Version: 16.2.1869542 (also reproduced on 17.0.1869541)
• BC Version: GB Business Central 26.5 (Platform 26.0.42867.0 + Application 26.5.38752.43518)
• Runtime: 15.2

Steps to Reproduce

1. Create an AL project with an empty dependencies array:

{
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "name": "My Extension",
  "publisher": "My Publisher",
  "version": "1.0.0.0",
  "brief": "",
  "description": "",
  "privacyStatement": "",
  "EULA": "",
  "help": "",
  "url": "",
  "logo": "./Images/logo.png",
  "dependencies": [],
  "screenshots": [],
  "platform": "1.0.0.0",
  "application": "26.0.0.0",
  "idRanges": [
    {
      "from": 50500,
      "to": 50599
    }
  ],
  "resourceExposurePolicy": {
    "allowDebugging": true,
    "allowDownloadingSource": false,
    "includeSourceInSymbolFile": false,
    "applyToDevExtension": false
  },
  "runtime": "15.2",
  "features": [
    "NoImplicitWith"
  ]
}

2. Configure launch.json to target a cloud sandbox
3. Press F5 or Ctrl+F5 to publish

Expected Behavior

• Publish should begin within seconds
• API requests to businesscentral.dynamics.com should be sent promptly
• Breakpoints should be hit and displayed in the debugger immediately

Actual Behavior

• The Microsoft.Dynamics.Nav.EditorServices.Host process spawns and immediately consumes 100% CPU
• No API requests are made for approximately 5 minutes
• The process appears stuck in initialization
• After ~5 minutes, the process finally proceeds and makes API requests normally
• Once deployed, hitting a breakpoint causes the debugger to freeze for a similarly long period (~5 minutes) before the breakpoint is shown in the editor

Diagnosis

Issue 1: Deployment Delay

Using ps aux, the debug process can be observed at 100% CPU:

USER  PID   %CPU %MEM CMD
user  12345 101  1.0  Microsoft.Dynamics.Nav.EditorServices.Host /startDebugging ...

The DebuggerServices.log (located in the AL extension's bin/linux/ directory) shows a ~5 minute gap between startup and first API request:

2025-12-21T20:06:41 Editor Services Host started!
2025-12-21T20:11:05 Sending request to https://api.businesscentral.dynamics.com/...

Note: The alc compiler works instantly (~8 seconds for 28 files), confirming the issue is isolated to the Editor Services Host initialization, not compilation.

Issue 2: Breakpoint Handling Freeze

After adding a dependency (System Application) to workaround Issue 1, deployment is fast. However, when a breakpoint is hit:

USER  PID   %CPU %MEM CMD
user  402600 85.8 0.9  Microsoft.Dynamics.Nav.EditorServices.Host /startDebugging ...

The DebuggerServices.log shows:

2025-12-21T21:09:22 Editor Services Host started!
2025-12-21T21:09:23 Sending request to https://api.businesscentral.dynamics.com/...
2025-12-21T21:09:24 Sending request to https://api.businesscentral.dynamics.com/...
2025-12-21T21:09:29 SignalR hub connection established with debugger context [...]
2025-12-21T21:09:29 SignalR connection send with Query parameters: "Authentication"
# NO FURTHER LOG ENTRIES despite 85% CPU for 5+ minutes

The process establishes SignalR connection successfully, but then enters a CPU spin with no further log output. The log file modification timestamp confirms no new writes occur after SignalR connection.

Workaround - Issue 1

Adding any dependency to app.json immediately resolves the deployment delay (Issue 1). For example, adding a dependency on System Application:

Note: This workaround does NOT fix the breakpoint handling freeze (Issue 2). No workaround is currently known for Issue 2.

{
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "name": "My Extension",
  "publisher": "My Publisher",
  "version": "1.0.0.0",
  "brief": "",
  "description": "",
  "privacyStatement": "",
  "EULA": "",
  "help": "",
  "url": "",
  "logo": "./Images/logo.png",
  "dependencies": [
    {
      "id": "63ca2fa4-4f03-4f2b-a480-172fef340d3f",
      "name": "System Application",
      "publisher": "Microsoft",
      "version": "26.0.0.0"
    }
  ],
  "screenshots": [],
  "platform": "1.0.0.0",
  "application": "26.0.0.0",
  "idRanges": [
    {
      "from": 50500,
      "to": 50599
    }
  ],
  "resourceExposurePolicy": {
    "allowDebugging": true,
    "allowDownloadingSource": false,
    "includeSourceInSymbolFile": false,
    "applyToDevExtension": false
  },
  "runtime": "15.2",
  "features": [
    "NoImplicitWith"
  ]
}

With this change, publish begins within 1-2 seconds. However, breakpoint handling still freezes as described in Issue 2.

Workaround - Issue 2

#8150

Additional Notes

• This bug appears to be Linux-specific (not confirmed on Windows/macOS)
• The issue occurs regardless of:
  • App ID (tested with multiple GUIDs including newly generated ones)
  • Whether the app is already installed in the sandbox
  • Project location on disk
  • Number of AL files in the project (tested with 1 file and 28 files)
  • Sandbox environment (tested with freshly created sandbox)
• Projects with dependencies (even just one) work correctly
• Compilation via alc command line is unaffected
• Other extensions in the same workspace that have dependencies deploy instantly

Issue 2 Specific Notes

• The debugger process maintains a single TCP connection to Business Central (68.219.163.6:443)
• Cursor/VS Code shows "paused on step" in the call stack panel but the debug UI is otherwise unresponsive
• The EditorServices.log shows frequent MessageReader's input stream ended unexpectedly errors when debug sessions are terminated
• The TreeError [DebugRepl] Tree input not set appears in renderer.log around the time breakpoints should be processed
• An Unexpected SIGPIPE error appears in the Extension Host logs
• This suggests a communication pipe issue between the editor and the debug adapter process on Linux