Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improving callstacks for calls out to golang #513

Open
TristanSpeakEasy opened this issue Jun 1, 2023 · 1 comment
Open

improving callstacks for calls out to golang #513

TristanSpeakEasy opened this issue Jun 1, 2023 · 1 comment

Comments

@TristanSpeakEasy
Copy link

Would be great if possible to be able to have useful callstack information for when the call stack contains information about a native call in the case of something like js -> go -> js.

An example:

failed to run script Error: here
    at templates/test5.stmpl:3:6:*(6)
    at github.com/speakeasy-api/easytemplate.(*Engine).init.func1.1 (native)
    at scripts/test.js:17:13:*(61)

where it would be amazing if the line github.com/speakeasy-api/easytemplate.(*Engine).init.func1.1 (native) contain better information as to the native method called and its line number

@mstoykov
Copy link
Contributor

mstoykov commented Jun 2, 2023

I would prefer if this is customizable more then it being done in a specific way for two reasons:

  1. For anyone who works with the js code only giving them go stack traces is only confusing. Having some way to make it so it says something that will be more understandable to them seems like a better UX/DX.
  2. I have a WIP hacky solution to a problem which involves going over the goja stacktrace and getting the file before/after a certain call to a go function.

Which means that I have the string representation hardcoded so I can match against it. And also that I have gone through some lengths so that the hardcoded value looks like something fairly okay for someone writing JS to understand the callstack.

I don't know what the API or the concrete thing to do should be, but it will be nice if we have mechanism to make this line in the stacktrace w/e we want.
Potentially also:

  1. Expanding it to the whole go stacktrace that has gone through
  2. completely dropping it
  3. replacing it in some fashion, either statically or dynamically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants