VSCode debugger

[davetapley]

It's not pretty, but it works:

Create a file called e.g. run-dagit.py:

from dagit.cli import main
main()

Add to your launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "run dagit",
            "type": "python",
            "request": "launch",
            "program": "run-dagit.py",
            "console": "integratedTerminal",
            "justMyCode": false,
            "cwd":"${workspaceFolder}",
            "env": {
                "DAGSTER_HOME": "/home/vscode/dagster_home"
            }
        }
    ]
}

Then Ctrl+Shift+P and Debug: Select and Start Debugging and choose run dagit.

Let me know if you have a more elegant solution 🔧

[davetapley]

And for dagster-daemon run I made a run-daemon.py:

from dagster._core.instance import DagsterInstance
from dagster.daemon.cli import _daemon_run_command

with DagsterInstance.get() as instance:
    _daemon_run_command(instance, {})

Same launch.json as above.

[sander76]

unfortunately this doesn't work anymore. Do you have an updated version maybe ?

[sander76]

this seems to work too:

    "configurations": [
        {
            "name": "Python: Module",
            "type": "python",
            "request": "launch",
            "module": "dagster",
            "justMyCode": true,
            "args": [
                "dev",
                "-f",
                "${workspaceFolder}/my-dagster-file.py"
            ]
        },

[lukemiloszewski]

This works for me:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Dagster: Debug Dagit UI",
      "type": "python",
      "request": "launch",
      "module": "dagster",
      "justMyCode": true,
      "args": ["dev"],
      "envFile": "${workspaceFolder}/.env"
    }
  ]
}

[tacastillo]

Sharing an example of how this can be replicated in Pycharm.

[DennisSchwartz]

I can run it this way, but I'm not able to actually set any break points which trigger. I'm running it with the -m option instead of -f. Maybe that makes a difference.

[yamhirotoCS]

Hey @DennisSchwartz @mficek
Pycharm user here. dagster dev -m my_module wasn't triggering the breakpoints either.

I was able to do so with the following settings in my debugger (source). Hopefully it will help!

dagster api grpc --module-name Our_dagster_module --host 0.0.0.0 --port 4266

I am however unable to catch exceptions I placed in my code, if you happen to have some explanations.

[venediktov]

@yamhirotoCS , @DennisSchwartz , @mficek , @tacastillo - so the problem with hitting a break point lies in the fact that jobs/ops/assets are running in sub-processes, Dagster spawns a different process for that.
PyCharm debugger needs to be configured to debug multiple processes please see Allow multiple Instances option:

There is another annoying but fixible error when you run Dagster in PyCharm in debug mode at least in the PyCharm 2023.3.3 it is
still a problem:

TypeError: 'Task' object is not callable debugging uvloop with asyncio support enabled`

https://youtrack.jetbrains.com/issue/PY-62467/TypeError-Task-object-is-not-callable-debugging-uvloop-with-asyncio-support-enabled

This one can be fixed by disabling python.debug.asyncio.repl in Registry

CTRL+Shift+A ( Mac OS Command + Shift + A ) 
Search for "Registry..."
Remove the checkmark at python.debug.asyncio.repl
Restart IDE

I hope it helps, I am able to debug Dagster jobs without an issue in PyCharm 2023.3.3 (Professional Edition)

[anotine10]

Hi @venediktov , i have tried to reproduce your setup, and i can not succeed to stop on breakpoints (with or without the allow multiple instances). Is there any other options that you ve configured?
Thanks

[venediktov]

@anotine10
PyCharm 2023.3.3 (Professional Edition) - what is the version of your PyCharm?

what is the version of your dragster?

Did you disable python.debug.asyncio.repl in PyCharm Registry?

Are you setting up break point in the OP function?

@op()
def  some_op_to_debug(context: OpExecutionContext) -> bool:
   context.log.info("I am setting break point on this line")

Do your breakpoints work in dragster at all, meaning if you set up a break point before dragster spawns a job->op some python code maybe executed before it runs job/op/asset , so the break points should work on those regardless of my settings. My settings are required only when dragster spawns a new process and runs jobs in the new process, only PyCharm Professional Edition can handle this type of debugging.

If those do not work then there is probably an issue with your debugger?

Are you executing your jobs via dragster web UI? Like running Debug configuration in PyCharm executing dragster dev in debug mode which should start daemon and web server, then using UI run the job you are trying to debug?

https://docs.dagster.io/guides/running-dagster-locally

I am debugging via locally running dragster dev process in my PyCharm as debug configuration , did you set up debug config for dagster dev ?

please share your Run/Debug Configuration if you can.

[EtienneT]

For future reference, here is a simple vscode configuration to launch dagster in debug mode. You can set breakpoint anywhere in assets, sensors etc etc.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "dagster dev",
            "type": "debugpy",
            "request": "launch",
            "module": "dagster",
            "args": [
                "dev",
            ],
            "subProcess": true
        }
    ]
}

[idiked]

@anotine10 @yamhirotoCS
PyCharm seems to have problems with debugging subprocesses in Python 3.11, 3.12: https://youtrack.jetbrains.com/issue/PY-61217/Cannot-attach-to-subprocess-when-debugging-with-Python-3.11-3.12

Switching to Python 3.10 has helped me. Additionally, it's necessary to disable python.debug.asyncio.repl in PyCharm Registry for Python 3.10