--debug flag should show full SDK stack traces inflight

[Chriscbr]

I tried this:

I ran wing test main.w with this code:

bring cloud;

let b = new cloud.Bucket();

test "call extern code" {
  b.get("invalid-key");
}

This happened:

I get an error as expected:

fail ┌ main.wsim » root/env0/test:call extern code
     │ Error: Object does not exist (key=invalid-key): Error: ENOENT: no such file or directory, open 'target/test/main.wsim/.state/c8962f0cd81d488253a50c5fab66f85708ed7b9545/files/8360c1a8d75639359aa1a0ebb0deb102'
     │   --> main.w:7:3
     │   | let b = new cloud.Bucket();
     │   | 
     │   | test "call extern code" {
     │ 7 |   b.get("invalid-key");
     │   |   ^
     └ at /Users/chrisr/dev/wing-test/main.w:7:3

But if I'm trying to debug something internal to Wing SDK, I'd like to see all JavaScript code instead of seeing the stack trace stop at "b.get()".

I expected this:

Passing --debug flag should show an unfiltered (or at least, less-filtered) stack trace

Is there a workaround?

No response

Anything else?

No response

Wing Version

0.59.45

Node.js Version

20.9.0

Platform(s)

MacOS

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.

[MarkMcCulloh]

Should this be a replacement for the DEBUG env flag or should setting --debug simply set DEBUG?

[eladb]

I think DEBUG and --debug should be the same

[MarkMcCulloh]

I think DEBUG and --debug should be the same

Makes sense, I'm down for that. Once we have better support for debugging wing itself I feel like we'll have to add more nuance to this. As a user, when I add --debug I don't necessarily want to get more verbosity for stuff outside my own code. I may not even want to change stacktraces at all, I may just want to attach a debugger.

[eladb]

Got it. Yes, maybe this should be --debugger or --attach or --inspect (homage to node's switch).

[MarkMcCulloh]

Also, the --debug feature should already work https://github.com/winglang/wing/blob/62513f9606760376c418402c5320c7ff717bd398/apps/wing/src/cli.ts#L102-L104

[MarkMcCulloh]

Just tried it and looks like it only works for preflight errors.

So the bug to fix here is to unify https://github.com/winglang/wing/blob/62513f9606760376c418402c5320c7ff717bd398/apps/wing/src/commands/test/test.ts#L212 to work more like https://github.com/winglang/wing/blob/62513f9606760376c418402c5320c7ff717bd398/apps/wing/src/commands/compile.ts#L162-L174 and respect DEBUG

[le-incroyable1-dev]

Hi there, I want to start contributing by working on this issue.

[staycoolcall911]

Bienvenue :) You got it @le-incroyable1-dev Let us know if you have any questions - either by leaving a comment here or on Slack.

[revitalbarletz]

@le-incroyable1-dev how is it going? do you need any help ?

[le-incroyable1-dev]

Hi, so just to clarify I need to add the stack trace in the error output in test.ts just like its done in compile.ts . I tried to do that but it doesn't really seem to have any difference in the error displayed??

[staycoolcall911]

Yes, that's what you should do. Are you making sure you're using your local version of wing when running wing test? Here are some instructions, just in case: https://www.winglang.io/contributing/start-here/development

[le-incroyable1-dev]

@staycoolcall911 I'm getting this error when I'm trying to run the local version of wing

I'm working on wsl

[MarkMcCulloh]

@le-incroyable1-dev Make sure to compile the CLI project first, run turbo compile -F winglang (or pnpm turbo compile -F winglang if you don't have turbo installed globally)

[le-incroyable1-dev]

@MarkMcCulloh Whenever I try to compile or build I get the same error, I tried to find a solution for this earlier too but no luck, I'm stuck here

[MarkMcCulloh]

@le-incroyable1-dev I see the cargo: not found error, I do remember trying to diagnose this. Is this still within wsl? What shell are you using? Do you know which shell profile(s) are being loaded in both an interactive and non-interactive shell?

I remember that you do have rustup/cargo installed and can access it from your normal shell usage, but from within pnpm/turbo you cannot. Would you be able to check if the PATH environment variable is set correctly from within whatever profile is loaded in those cases?

A possible debug step may be to create a completely separate directory outside the repo and to create a package.json with the following contents:

{
  "scripts": {
    "test": "pwd && echo $SHELL && echo $PATH && which cargo"
  }
}

Then run pnpm test and post the output here

[le-incroyable1-dev]

Okay, so I'll work on fixing my local build. Meanwhile, I'm trying to work on the issue through a codespace. I've noticed that the test.ts file uses the TestResult object type to display the error message, and the implementation of TestResult doesn't seem to have a workaround for getting the entire error stack trace. Could anyone suggest something?

[MarkMcCulloh]

I believe TestResult.error should already have the full verbose error and it's getting trimmed by prettyPrintError. I think my initial advice here should work https://github.com/winglang/wing/issues/5883#issuecomment-1989366155 Another interesting improvement would be to refactor prettyPrintError to be able to optionally include the verbose stack trace too so we avoid the duplicated logic.

[le-incroyable1-dev]

@MarkMcCulloh as you said, TestResult.error does include the full verbose error. So just to clarify, could you please explain what you meant by refactor prettyPrintError to be able to optionally include the verbose stack trace too so we avoid the duplicated logic. Just like it says in the issue, I've changed the code so that the debug flag shows the complete error, and by default it prints the trimmed error only.

[revitalbarletz]

@MarkMcCulloh I think that refactoring orettyPrintError should be addressed in a different PR as part of a different issue. @le-incroyable1-dev can you share your current changes through a PR?

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 90 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!