Common problems when debugging Deephaven
This guide describes common Deephaven-specific issues you may encounter when debugging Groovy code.
Note
These issues are specific to how Deephaven works and are not related to your debugger setup. The examples use an application mode script loaded at server startup. The same limitations apply to code entered interactively in the Deephaven console.
Setup for the examples
The examples below use an application mode script loaded at server startup. Inside your Docker debug project (the one containing docker-compose.yml), create the following structure:
debug-demo.app:
debug-demo.groovy:
Note
Define functions as closures (assigned to a variable without def) rather than as regular Groovy methods. Closures are placed into the query scope and can be called from formula strings. Methods defined with def are not accessible to the formula compiler.
Then add -Ddeephaven.application.dir=/data/app.d to START_OPTS in your docker-compose.yml:
When you restart the container, the script loads automatically.
Breakpoints in app mode scripts are not hit
Problem: You've set a breakpoint in an app mode script, IntelliJ is connected, but execution runs through the breakpoint without pausing.
Cause: Deephaven compiles app mode scripts dynamically before evaluating them. It prepends a package io.deephaven.dynamic; declaration to the script content, which shifts all line numbers by one in the compiled class. The compiled class also receives a path-derived internal name (for example, _data_app_d___debug_demo_groovy) rather than the original filename. IntelliJ cannot reliably map these compiled classes back to your source file, so breakpoints set in your .groovy files are never hit.
This applies to both app mode scripts and code entered in the Deephaven console.
Workaround: Use println to trace execution. Output appears in the container logs:
Update debug-demo.groovy to add trace output:
When the server starts and loads the script, tEager evaluates immediately and you will see 20 lines of output in the logs (two per row, 10 rows). tLazy produces no output at startup — addOne is not called until a downstream operation forces evaluation.
For line-by-line breakpoint debugging of user Groovy code, see source debugging setup.
Lazy evaluation of some table operations
Some Deephaven table operations — including updateView — use lazy evaluation, where results are not computed until a downstream operation requires them. select evaluates immediately and stores the results.
The debug-demo.groovy script creates both kinds of tables:
updateView defers calling addOne until a downstream operation forces the result to materialize. select evaluates all expressions immediately and stores the results.