Skip to content

Java Debugger Extension

issuelens[bot] edited this page Sep 23, 2026 · 5 revisions

Java Debugger Extension

microsoft/vscode-java-debug owns the VS Code-side Java debugger extension. This page records the extension's model-facing Java launch guidance and repository team-memory caller; debug-protocol handling remains documented in Java Debug Server.

Model-facing Java launch failure policy

At source revision 63a6b9b5360ef66bdca2f7ebb32f2ff76384f25a, the extension's Java launch context and java-launch-troubleshooting skill direct run/launch requests to the debugger language-model tools. For debug_java_application:

  • After the first failure or timeout, report and diagnose the result; do not automatically retry the tool or relaunch through terminal commands.
  • A timeout means startup is unconfirmed. One get_debug_session_info check and inspection of existing terminal output are allowed; do not poll repeatedly or stop the original launch solely because the wait expired.
  • A new launch attempt is permitted only after an identified cause is fixed or the user explicitly requests a retry. Check for an existing session first and do not replace an active session without explicit restart intent.

This is extension-side tool and guidance behavior, not a claim about Java Debug Server DAP handling or target-JVM state.

Validation boundary

test/languageModelToolLaunchPolicy.test.ts covers both launch wait modes, confirmed startup, returned failures, exceptions, disabled no-config debugging, timeout telemetry, and consistency between manifest/instruction/skill guidance. The test asserts that timeouts are reported as unconfirmed startup without an automatic relaunch or stop of the original session.

Repository team-memory caller

At source revision e25d4776586fd38301bb3efdda74f1159331f85f, PR #1702 changes .github/workflows/team-memory-post-merge.yml from a closed-PR trigger to push on main. The workflow also retains manual recovery through workflow_dispatch with a required string pull_request_number input.

The same workflow's concurrency and jobs.team-memory configuration establish:

  • Opt-in requires ISSUELENS_TEAM_MEMORY_ENABLED == 'true'; the run ref must match the repository's live default branch, and the event must be push or workflow_dispatch. The static push filter remains main.
  • Concurrency groups retain the repository-scoped issuelens-…-team-memory-… prefix, using the push's after SHA, then the manual PR number, then the run ID. cancel-in-progress remains false.
  • The job runs on ubuntu-latest with a 30-minute timeout. Its sole step calls microsoft/IssueLens/.github/actions/issuelens@2b5317815e15179899014a02c41678620ce2d390 with request-type: team-memory and the manual PR input; there is no checkout step.
  • Top-level permissions are empty; job permissions are contents: read, pull-requests: read, and id-token: write. Existing Azure/agent secret references remain wired to the action, with output-mode: activity and summary-mode: status.

These are caller-configuration facts verified in the workflow at the full source SHA above, not verification of the external action's implementation, Azure federation readiness, a successful live run, or deployment. Source identity: microsoft/vscode-java-debug#1702:e25d4776586fd38301bb3efdda74f1159331f85f.

Sources

Merged in microsoft/vscode-java-debug PR #1701, source revision 63a6b9b5360ef66bdca2f7ebb32f2ff76384f25a:

Clone this wiki locally