Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
[Feature] Remote Analysis
See original GitHub issueIs your feature request related to a problem? Please describe.
Dbux’s Runtime Server is currently hard-coded to live on port 3374 and @dbux/runtime connects to localhost:3374. Thus, remote applications cannot currently be debugged.
Describe the solution you’d like
This should be configurable in order to allow debugging remotely executed code as well as containers.
Is this covered by any of the Dbux known limitations or future-work items? If so, which?
Important
Please let us know on discord and up-vote this feature, if this issue is blocking you from using Dbux.
Issue Analytics
- State:
- Created 2 years ago
- Comments:14 (14 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
…OK I realized, the port forwarding “works” only to the extent that it successfully loads the trace into dbux in VSCode.
But then it obviously fails to do anything useful with it because the file doesn’t exist locally.
So I guess the only working way (which luckily is also the most straight forward one) is to use the remote SSH extension for VSCode and simply use dbux in the remote VSCode session.
Will probably look into Volta indeed, because I’m currently using asdf and it annoys the heck out of me.