al_publish LM tool hangs after successful full dependency tree publish when debug: false
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- javascript, vscode
- Domain
- tooling
Research direction
Start at executeCore and trace the command selected for fulldependencytree alongside the existing al.publishNoDebug path. Compare the al.fullDependencyPublish command registration and the al/fullDependencyPublish request flow; done means debug:false returns the tool result after publishing without starting a debug session.
Written by the indexing model from the issue text.
Description
1. Describe the bug
When calling the al_publish LM tool with fulldependencytree: true and debug: false, the tool never returns after a successful publish. All projects are published successfully and "Done publishing the full dependency tree." is logged to the AL output channel, but the tool call hangs indefinitely.
2. To Reproduce
Steps to reproduce the behavior:
- Open a workspace with a multi-project AL solution.
- Invoke the
al_publishLM tool via a GitHub Copilot agent with:debug: falsefulldependencytree: true- Eg. write this in the copilot chat:
call #al_publish with debug: false, fulldependencytree: true
- Observe the AL output channel ΓÇö all projects publish successfully.
- Observe the agent ΓÇö it hangs indefinitely after the last log line.
No AL code snippet required ΓÇö the issue is in the tool's command dispatch logic, not in AL source code.
3. Expected behavior
After all projects are published and "Done publishing the full dependency tree." is logged, the al_publish tool should return a result to the calling agent without starting a debug session, consistent with the behavior of debug: false in all other publish paths.
4. Actual behavior
The tool never returns. The AL output log ends with:
[2026-06-22 11:49:19.03] Success: The package 'Me_MyApp_27.9.0.0.app' has been published to the server.
[2026-06-22 11:49:19.03] Done publishing project 2 of 2: MyApp
[2026-06-22 11:49:19.03] Done publishing the full dependency tree.
No further output is produced and the agent never proceeds.
Root cause analysis
In executeCore (the LM tool), the debug parameter is respected for all publish paths except fulldependencytree: true:
// Incremental and standard paths: debug flag respected ✅
r === a.Incremental
? (c = t ? "al.incrementalPublish" : "al.incrementalPublishNoDebug")
: (c = t ? "al.publish" : "al.publishNoDebug")
// Full dependency path: debug flag silently ignored ❌
u ? (c = "al.fullDependencyPublish")
al.fullDependencyPublish unconditionally calls initalizeDebugAdapterService.getDebugAdapterConfiguration() and passes it to the language server request (al/fullDependencyPublish). The language server publishes all projects but its LSP response is gated on a subsequent debug session start ΓÇö which never completes when debug: false was requested. The yield serverProxy.sendRequest(...) awaits forever.
There is no al.fullDependencyPublishNoDebug counterpart, which is the missing piece.
Suggested fix
Add an al.fullDependencyPublishNoDebug command (mirroring the existing al.publishNoDebug) and dispatch to it when fulldependencytree: true and debug: false.
5. Versions:
- AL Language: 17.0.2273547 and 18.0.2498801
- Visual Studio Code: 1.125.1
- Business Central: 28.1.49838.51179
- List of Visual Studio Code extensions that you have installed: N/A
- Operating System:
- Windows
- Linux
- MacOS
Final Checklist
- Search the issue repository to ensure you are reporting a new issue
- Reproduce the issue after disabling all extensions except the AL Language extension
- Simplify your code around the issue to better isolate the problem
Internal work item: AB#648586
- Dominant language
- PowerShell
- Stars
- 881
- Forks
- 285
- Avg merge
- 3d 36m
- Merged PRs (30d)
- 1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/AL
-
accepted al-tools bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
AL 18.0.2732683 regression: System.Drawing types cannot be resolved from assembly probing paths Open
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
accepted packaging
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
hemilabs/ui-monorepo#2332 ·
-
Help-Wanted Needs-Triage Package-Update
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
microsoft/winget-pkgs#438662 ·
-
priority: p3
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
googleapis/librarian#7636 ·
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
olcf/olcf-test-harness#278 · 1 comment ·