Skip to content

fix(dap): skip enrich_config for attach mode#494

Merged
s1n7ax merged 1 commit into
nvim-java:mainfrom
fobbyal:fix/dap-attach-skip-enrich-config
Jun 6, 2026
Merged

fix(dap): skip enrich_config for attach mode#494
s1n7ax merged 1 commit into
nvim-java:mainfrom
fobbyal:fix/dap-attach-skip-enrich-config

Conversation

@fobbyal

@fobbyal fobbyal commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

Summary

Setup:enrich_config (lua/java-dap/setup.lua:41) asserts that
mainClass is present, but attach configs don't have one and don't
need one — the JVM is already running and chose its own main class,
classpath, and java executable.

The assert fires before any check on request type, so every Java
DAP attach config fails today unless callers pre-populate dummy
values for the five fields the early-return checks (mainClass,
projectName, modulePaths, classPaths, javaExec).

This PR adds an early return for config.request == 'attach',
skipping the launch-specific enrichment (build_workspace,
resolve_classpath, resolve_java_executable) which are all
meaningless for an already-running JVM.

Reproduction

Register a Java attach config in dap.configurations.java:

table.insert(dap.configurations.java, {
  type = 'java',
  request = 'attach',
  name = 'Java Attach :5005',
  hostName = '127.0.0.1',
  port = 5005,
})

Start a JDWP-listening JVM (e.g. mvn spring-boot:run -Dspring-boot.run.jvmArguments='-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005'), then :DapContinue and pick that config.

Before this PR:

To enrich the config, mainClass should already be present
.../nvim-java/lua/java-dap/setup.lua:54

After this PR: the attach proceeds, the DAP session initialises,
and breakpoints work as expected.

Why the early-return location

The existing five-field early-return (lines 45-47) lets callers
satisfy the assert by passing dummy values. That works as a
workaround but is unintuitive — attach configs shouldn't have to
fake fields they semantically don't have. Adding the
request == 'attach' short-circuit ahead of it expresses the actual
invariant: attach configs need no enrichment, full stop.

Test plan

  • Local install patched with the same change; :DapContinue
    pick attach config → DAP session attaches, dap-ui opens, breakpoints
    fire on the running JVM.
  • Verified request == 'launch' configs still go through the
    full enrichment path (no regression — the early return only fires on
    'attach').

🤖 Generated with Claude Code

Setup:enrich_config asserts that mainClass is present, but attach
configs don't have one and don't need one — the JVM is already running
and chose its own main class, classpath, and java executable. The
assert fires before any check on request type, making every attach
config in nvim-dap fail unless callers pre-populate dummy values for
the five fields the early-return checks.

Adding an early return for `request == 'attach'` skips the
launch-specific enrichment (build_workspace, classpath resolution,
java executable resolution) which are all meaningless for an already-
running JVM.

Reproduction: register a Java attach config in dap.configurations.java
with type='java', request='attach', hostName='127.0.0.1', port=5005,
then :DapContinue. Today it errors with:

    To enrich the config, mainClass should already be present
    .../java-dap/setup.lua:54

After this fix, the attach proceeds and dap-ui opens against the
running JVM as expected.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
@s1n7ax s1n7ax merged commit ccd76f9 into nvim-java:main Jun 6, 2026
8 checks passed
@s1n7ax

s1n7ax commented Jun 6, 2026

Copy link
Copy Markdown
Member

Thanks for the contribution <3

@fobbyal

fobbyal commented Jun 7, 2026

Copy link
Copy Markdown
Contributor Author

@s1n7ax np... it is mostly claude code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants