aws-toolkit-jetbrains icon indicating copy to clipboard operation
aws-toolkit-jetbrains copied to clipboard

Rider Lambda debugging doesn't work: Timeout waiting for Debugger Worker process to start

Open koendhondt opened this issue 5 years ago • 24 comments

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

  1. Using the New project wizard, create a LambdaEmptyFunction project (or any other Lambda project)
  2. Configure credentials;
  3. Create a Local run configuration for the project;
  4. 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

koendhondt avatar Nov 27 '19 08:11 koendhondt

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.

abrooksv avatar Nov 27 '19 13:11 abrooksv

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...

koendhondt avatar Nov 27 '19 14:11 koendhondt

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

abrooksv avatar Nov 27 '19 17:11 abrooksv

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

justinmk3 avatar Nov 29 '19 19:11 justinmk3

@koendhondt, did you install Rider from Toolbox or from an installer?

sdubov avatar Dec 02 '19 05:12 sdubov

Downloaded Rider dmg image from jetbrains and ran the installer. Used automatic upgrades to upgrade ever since.

koendhondt avatar Dec 02 '19 08:12 koendhondt

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 avatar Dec 02 '19 09:12 koendhondt

@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.

sdubov avatar Dec 02 '19 15:12 sdubov

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.

koendhondt avatar Dec 03 '19 09:12 koendhondt

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.

sdubov avatar Dec 03 '19 20:12 sdubov

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...

mattdarwin avatar Mar 18 '21 11:03 mattdarwin

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

brunocasarotti avatar May 04 '22 12:05 brunocasarotti

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.

rlinyard avatar May 05 '22 15:05 rlinyard

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.

image

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.

image

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.

image

Session fails and no docker container is created

image

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

image

Debug session runs but fails to attach debugger.

image

image

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

alzakx avatar May 06 '22 16:05 alzakx

Does increasing the debugger attachment timeout in Rider's Registry seem to help?

  1. Search for Registry using Find Action (⇧ ⌘ A, or Ctrl+Shift+A)
  2. Set aws.debuggerAttach.timeout to a higher value (like ~300000)
Screen Shot 2022-05-06 at 11 36 48 AM

Screen Shot 2022-05-06 at 11 35 16 AM

rli avatar May 06 '22 18:05 rli

@rli waited 10 minutes for the debugger to attach to the process and it never did. Seems to be related somewhere else.

alzakx avatar May 06 '22 18:05 alzakx

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 avatar May 06 '22 19:05 rli

@rli It doesn't sir.

image

alzakx avatar May 06 '22 22:05 alzakx

Is there any update?

berkayyerdelen avatar May 11 '22 12:05 berkayyerdelen

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 avatar Jun 06 '22 15:06 bdrupieski

@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.

image

brunocasarotti avatar Jun 06 '22 17:06 brunocasarotti

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)

BradKnowles avatar Jul 12 '23 21:07 BradKnowles

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

image

sliedig avatar Aug 28 '23 14:08 sliedig

@sliedig Did you ever find a solution?

abhishek-parative avatar Feb 07 '24 20:02 abhishek-parative