fix(lmtool): stop double-counting classNameDetection on every invoke

[wenytang-ms]

Update (review pass): the original PR description claimed this dedup would deflate the observed noPackage failure rate "from 49% to ~25%". That claim is wrong — the duplicate findFullyQualifiedClassName call in debugJavaApplication only ran the FS walk a second time; recordLaunchInternal({name:'classNameDetection'}) was only emitted from constructDebugCommand. So:

• ✅ This PR still removes one full file-system walk on every simple-class-name launch (real perf win, real code-clarity win)
• ❌ The observed 49% noPackage rate is not inflated 2× — it is a real signal that still needs investigation (see perf(telemetry): unblock per-tool quality analysis (GDPR annotations + diagnostic fields + InvocationGuard) #1650 / 06-深度诊断-PR定向-2026-06-09.md P0-3)

Problem

debugJavaApplication (the debug_java_application LMT handler) was calling
findFullyQualifiedClassName twice per invocation for the simple-class-name path:

1. Once inside constructDebugCommand (to resolve the FQN for the actual
   java -cp ... ClassName command), where it also emitted
   recordLaunchInternal({name: 'classNameDetection', detected: <bool>}).
2. Once in the caller, immediately after constructDebugCommand, just to
   build the user-facing targetInfo string ("com.example.App (detected from App)").

findFullyQualifiedClassName walks src/main/java (or equivalent) recursively
up to MAX_FILE_SEARCH_DEPTH, stats every .java file, and reads candidates
to extract the package. Doing it twice on every launch is wasted work on the
hot path.

Fix

• Move the detection call (and the classNameDetection telemetry emit) into
  the caller (debugJavaApplication, Step 3), so it runs exactly once per
  invocation.
• Add an optional third parameter preDetectedClassName?: string | null to
  constructDebugCommand. When the caller has already resolved the FQN, it
  passes that result in and constructDebugCommand skips re-detection.
• Reuse the same resolved name in the targetInfo formatting block — no
  second FS walk.

Scope

• No behavior change for users. The resolved FQN, the constructed
  debugjava command, and the telemetry event content are identical.
• No telemetry-count change — classNameDetection still fires exactly
  once per invocation (it always did; the second call site was not emitting).
• One extra FS walk eliminated per simple-class-name launch.

Test

• npx tsc --noEmit — clean
• npm run tslint — clean
• Diff: +44 / -27 in 1 file (after review reword)

Validation plan

This PR is a refactor, so there is no metric we expect to move. Post-ship
sanity check: per-invocation classNameDetection event volume should stay
flat (1:1 with debug_java_application.invoke). If it drops by ~50%, that
would actually confirm a pre-existing 2× emission elsewhere we missed; if it
stays equal, the refactor is a pure perf win, which matches the code reading.

RawEventsVSCodeExt
| where ServerTimestamp > ago(14d)
| where ExtensionName == "vscjava.vscode-java-debug"
| extend op = tostring(Properties["operationname"])
| where op endswith "debug_java_application.invoke"
   or op endswith "classNameDetection"
| summarize count() by op, extversion = tostring(Properties["common.extversion"])
| order by extversion desc, op

Related

• Independent of perf(telemetry): unblock per-tool quality analysis (GDPR annotations + diagnostic fields + InvocationGuard) #1650 (telemetry contract) and fix(lmtool): reframe timeout messages as transient + retry-friendly to nudge model retries #1652 (timeout messaging).
  All three can land in any order.
• The actual 49% noPackage rate is investigated in perf(telemetry): unblock per-tool quality analysis (GDPR annotations + diagnostic fields + InvocationGuard) #1650's structured
  classNameDetection.failed event (with failureReason ∈
  noPackageDeclaration / fileNotFound / sourceDirMissing / parseError).
• Same diagnostic context: debugagent/06-深度诊断-PR定向-2026-06-09.md.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[Copilot]

Pull request overview

This PR refactors debugJavaApplication to resolve a simple Java class name to a fully-qualified class name once per invocation and reuse that result for both command construction and the user-facing targetInfo message.

Changes:

• Adds a single, caller-owned findFullyQualifiedClassName lookup and reuses its result across the launch flow.
• Updates constructDebugCommand to accept an optional preDetectedClassName to avoid redundant lookups and centralize telemetry emission at the caller.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.