aws-toolkit-jetbrains
aws-toolkit-jetbrains copied to clipboard
Rider Lambda debugging doesn't work: Timeout waiting for Debugger Worker process to start
Describe the bug Attempting to run a local lambda debug session fails with the following error message:
Error running '[Local] LambdaEmptyFunction': Timeout waiting for Debugger process to start
To reproduce
- Using the New project wizard, create a LambdaEmptyFunction project (or any other Lambda project)
- Configure credentials;
- Create a Local run configuration for the project;
- Select Run -> Debug
The sam build starts, and then the IDE reports 'waiting for debugger' until it times out.
The IDE event log tab shows the following messages: 09:14 Debugger attach error: Unable to attach to debugger process. 09:14 Error running '[Local] LambdaEmptyFunction::LambdaEmptyFunction.Function::FunctionHandler': Timeout waiting for Debugger Worker process to start
Expected behavior
Screenshots
Your Environment
- OS: MacOS Mojave 10.14.6
- JetBrains' Product: Rider
- JetBrains' Product Version: 2019.2.3
- Toolkit Version: 1.8-192
- SAM CLI Version: SAM CLI, version 0.22.0
- JVM/Python Version: jvm 1.8.0_202, Python 2.7.10, Python 3.7.4
- Docker Desktop Version: Community edition, version 2.1.0.5
- Docker Engine Version: Docker version 19.03.5, build 633a0ea
Are there any logs in the debug tool window?
Try to use run first so that it has time to download the docker image first.
I do not even get to the Debug tool window, it only shows as a greyed-out tab with the error message hovering above it, and it disappears when I try to select the tab.
Using run first does not make any difference.
I have installed sam cli using the instructions on https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install-mac.html, and just upgraded to 0.34.0, which does not help.
These instructions however do contain one (very) puzzling statement. To confirm a proper docker installation, the following is suggested:
'After Docker is installed, verify that it's working. Also confirm that you can run Docker commands from the AWS SAM CLI (for example, docker ps). You don't need to install, fetch, or pull any containers––the AWS SAM CLI does this automatically as required. '
I know how to run docker, and sam is installed and running, but how do you run 'docker ps' using SAM CLI? There is no sam command that allows me to run an arbitrary command...
The phrasing does sound odd. I will talk to the doc writers. It also is not needed anymore since we do the check for you now: https://github.com/aws/aws-toolkit-jetbrains/blob/32404a5b50822d6d259d5c75466432dd1f971842/jetbrains-core/src/software/aws/toolkits/jetbrains/services/lambda/execution/local/SamRunner.kt#L26
Sounds similar to https://github.com/aws/aws-toolkit-jetbrains/issues/784 and https://github.com/aws/aws-toolkit-jetbrains/issues/642 . The plumbing for Rider might be different, but perhaps the same root cause: need explicit host instead of "localhost"?
Related PR: https://github.com/aws/aws-toolkit-jetbrains/pull/1402
@koendhondt, did you install Rider from Toolbox or from an installer?
Downloaded Rider dmg image from jetbrains and ran the installer. Used automatic upgrades to upgrade ever since.
Don't know if it helps you out, but here's what I tried so far:
- purged all my docker containers (docker system prune -a), docker images returns an empty list;
- restart Rider, load solution and run a debug session, Timeout waiting for debugger appears;
- docker images now lists (after some time): REPOSITORY TAG IMAGE ID CREATED SIZE lambci/lambda dotnetcore2.1 4cef2fb5726d 31 hours ago 1.03GB
- restart Rider
- run 'watch -n 1 docker ps' and start KiteMatic from Docker Desktop (KiteMatic shows an empty container list)
- load solution and run debug session again, timeout occurs again.
- nothing is show in docker ps output, KiteMatic container list remains empty;
- run a 'Run' session, docker ps output shows (briefly) a running container, KiteMatic container list now contains a container based on the lambda:dotnetcore2.1 image;
- rerunning the same command shows that the existing container is removed and replaced by new one one;
- running a Debug session again shows the existing container being removed, and no new one being created.
As far as I can tell, there is no docker container being created when I run a debug session. If you could tell me how I can enable debug logging in Rider and/or AWS toolkit I might be able to gather some additional logs and/or information for you.
@koendhondt, could you please check Docker Preferences... > File Sharing and make sure you have /Applications path added here? It maps a Debugger directory under your Rider installation folder to Docker container volume when you run debug.
Thanks @sdubov , that was it. The problem was a combination with pycharm: I have this installed too, and have the AWS toolkit for pycharm as well. When I looked at the shared paths, it contained the following: /Applications/PyCharm.app/Contents/helpers
Removing this and adding /Applications did work.
Perhaps the aws toolkit installer needs to add /Applications/Rider.app/[path to tools] to the shared paths as well? At least it could contain the logic to check if /Applications is already in shared paths or add some type of message to notify the user.
At least it could contain the logic to check if /Applications is already in shared paths or add some type of message to notify the user.
That's true. We should definitely check this before running debug. Have this change in my todo list already :) Thank you.
I had the same issue, and @sdubov your suggestion has fixed it. But @sdubov it would be great if the check could be added to the code as per your TODO list...
I am running on a similar issue when trying to debug lambda functions locally.
[Info] Waiting for the debugger to attach...
Attach Debugger has failed: org.jetbrains.concurrency.MessageError: Timeout waiting for Debugger Worker process to startAttach Debugger has failed: org.jetbrains.concurrency.MessageError: Timeout waiting for Debugger Worker process to start12 has failed: org.jetbrains.concurrency.MessageError: Timeout waiting for Debugger Worker process to start12 has failed: org.jetbrains.concurrency.MessageError: Timeout waiting for Debugger Worker process to start
Is there any workaround that I can try?
Rider: Build #RD-221.5591.20, built on April 28, 2022 AWS Toolkit: 1.43-221
I'm having this issue, too. I install Rider via the Toolbox and I have added /Users/[me]/Library to docker FILE SHARING (MacOS 12.3.1 with M1 Max processor). This is a dotnet6 HelloWorld project.
Same issue here.
Built a solution NOT using the Lambda project template on Rider for DotNet6, so no template.yml for me. Added an AWS Lambda function handler as a C# class and followed instructions to install the SAM Cli and my AWS Credentials. Created a Local Run Configuration for running a Debug session with the From Handler option selected instead of From Template.

First: Handler is not detected nor it can be filled in with code suggestions. Adding the handler path manually still shows it cannot find handler.

Tried running the Debug session after manually adding the handler path. Rider prompted to Continue Anyway regardless of the error present on the Run Configuration.

Session fails and no docker container is created

Tried adding SAM Invoke parameters for -t to point the the template.yml file generated under .aws-sam/build/

Debug session runs but fails to attach debugger.


Docker container does get created.
Sometimes an error message shows as Attach Debugger has failed: org.jetbrains.concurrency.MessageError: Timeout waiting for Debugger Worker process to start
Rider: Build #RD-221.5591.20, built on April 28, 2022 AWS Toolkit: 1.43-221 Docker Desktop 4.7.1 (77678) (Running on Windows 10 Enterprise Version 20H2 Build 19042.1645
Does increasing the debugger attachment timeout in Rider's Registry seem to help?
- Search for
RegistryusingFind Action(⇧ ⌘ A, or Ctrl+Shift+A) - Set
aws.debuggerAttach.timeoutto a higher value (like ~300000)

@rli waited 10 minutes for the debugger to attach to the process and it never did. Seems to be related somewhere else.
Thanks for checking. If you run:
docker exec -t <container> sh -c "tail -n +1 /proc/*/cmdline"
After Find DotNet process PID reports success, does JetBrains.Debugger.Worker.exe appear in the output?
$ docker exec -t jolly_blackwell sh -c "tail -n +1 /proc/*/cmdline"
==> /proc/129/cmdline <==
tail-n+1/proc/129/cmdline/proc/14/cmdline/proc/1/cmdline/proc/44/cmdline/proc/self/cmdline/proc/thread-self/cmdline
==> /proc/14/cmdline <==
/var/lang/bin/dotnetexec--depsfile/var/task/HelloWorld.deps.json--runtimeconfig/var/task/HelloWorld.runtimeconfig.json/var/runtime/Amazon.Lambda.RuntimeSupport.dllHelloWorld::HelloWorld.Function::FunctionHandler
==> /proc/1/cmdline <==
/var/rapid/aws-lambda-rie--log-levelerror/var/runtime/bootstrap
==> /proc/44/cmdline <==
/tmp/lambci_debug_files/linux-x64/dotnet/dotnet/tmp/lambci_debug_files/JetBrains.Debugger.Worker.exe--mode=server--frontend-port=60481--backend-port=60482
[^ this line]
@rli It doesn't sir.

Is there any update?
Is there a known workaround for this until @rli's fix in https://github.com/aws/aws-toolkit-jetbrains/pull/3156 is merged and deployed?
@bdrupieski as a workaround for this you can download the dotnet lambda test tool and configure your Run/Debug Configuration to execute the .exe you downloaded. You should be able to debug your lambda function with that.

I am experiencing this same issue running Rider 2023 on Windows 10. One thing to note, very quickly after launching, the IDE switches to the Debug Console displays Can't initialize debug session. Process with ID 15 is not running.
About Info
JetBrains Rider 2023.1.3
Build #RD-231.9161.46, built on June 21, 2023
Runtime version: 17.0.7+10-b829.16 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 10.0
.NET 7.0.2 (Server GC)
GC: G1 Young Generation, G1 Old Generation
Memory: 1500M
Cores: 8
Registry:
ide.experimental.ui=true
ide.new.project.model.index.case.sensitivity=true
vcs.empty.toolwindow.show=false
database.show.search.tab=false
rdclient.asyncActions=false
aws.debuggerAttach.timeout=300000
Non-Bundled Plugins:
com.github.patou.gitmoji (1.12.2)
com.github.lppedd.idea-conventional-commit (0.22.0)
IdeaVIM (2.3.0)
org.intellij.plugins.hcl (231.8109.91)
com.intellij.ideolog (222.1.0.0)
cognitivecomplexity-rider (2023.1.0)
com.intellij.resharper.StructuredLogging (2023.1.0.296)
me.seclerp.rider.plugins.efcore (231.1.4)
aws.toolkit (1.71-231)
I had the same problem with the latest builds and IDE versions
<< truncated >>
Created publish archive (/Users/<<user>>/Dev/github.com/<<user>>/<<project>>/Unicorn.Contracts/.aws-sam/build/ContractEventHandlerFunction/ContractsService.zip).
Lambda project successfully packaged: /Users/<<user>>/Dev/github.com/<<user>>/<<project>>/Unicorn.Contracts/.aws-sam/build/ContractEventHandlerFunction/ContractsService.zip
Updated source_hash and manifest_hash field in build.toml for function with UUID b444863d-389d-421c-9705-f88358e2729b
Build Succeeded
Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml
Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided
/usr/local/bin/sam local invoke ContractEventHandlerFunction --template /Users/<<user>>/Dev/github.com/<<user>>/<<project>>/Unicorn.Contracts/.aws-sam/build/template.yaml --event "/private/var/folders/65/5d29z1cn1cncgg519ztv4sl80000gr/T/[Local] FunctionHandler-event.json" --debugger-path /Users/<<user>>/Applications/Rider.app/Contents/lib/ReSharperHost --debug-port 56668 --debug-port 56669
Invoking Unicorn.Contracts.ContractService::Unicorn.Contracts.ContractService.ContractEventHandler::FunctionHandler (dotnet6)
Local image is up-to-date
Using local image: public.ecr.aws/lambda/dotnet:6-rapid-x86_64.
Mounting /Users/<<user>>/Dev/github.com/<<user>>/<<project>>/Unicorn.Contracts/.aws-sam/build/ContractEventHandlerFunction as /var/task:ro,delegated, inside runtime container
START RequestId: 14f094f8-656a-4ffe-9cd0-5e749742cb63 Version: $LATEST
[Info] Waiting for the debugger to attach...
Attach Debugger has failed: org.jetbrains.concurrency.MessageError: Timeout waiting for Debugger Worker process to startAttempt Debugger Attachment has failed: org.jetbrains.concurrency.MessageError: Timeout waiting for Debugger Worker process to start
and then the debugging session won't stop
@sliedig Did you ever find a solution?