Dow to debug Jobs and Triggers code?

I’m trying to debug my quite complex job code and when I get an exception like

TypeError: Cannot read property ‘get’ of undefined

I can’t find the code line where the problem appeared - there is no stack trace.
Also the same is with triggers. I need to console log and binary eliminate places where it could appear - it’s really annoying.

The only code showing stack trace is a Cloud Functions - which is good.

How do you guys debug jobs and triggers? Maybe I’m doing something wrong?
Why it’s not showing a full stack trace with my code and line, is that some parse Node.js engine problem?

The best way is setting up a local development environment for debugging and avoid debugging directly in the server. Once you have it running on your local machine, it would be the same of debugging a regular Node.js app.

I’m debugging it locally, it doesn’t mean that I can tell which line of code is causing the problem in my cloud job. It’s like debugging in C which I was doing 20 years ago. I would expect something more user friendly in the 21st century.

Since you are debugging it in your local machine, you should be able to see the line of code and also the complete error stack. Are you using any IDE for debugging?

@avramo, for security reasons triggers and cloud code functions do not return stack trace to client. Also returning unexpected errors to client is not considered as a best practice today.

To avoid headache and avoiding returning stack trace to client I can suggest you to put a try catch around your code and handle properly the error depending of the error source. Then depending of the Node Env, you can add some console.error() to get the full stack trace :slight_smile: I hope it can help :smiley:

2 Likes

Do you mean I could even use breakpoints in the code?
How to do this, please let me know - I’m using Visual Studio Code.

Moumouls, thank you but I can get the cloud code function stack trace, and I can’t get the stack trace of Triggers and Jobs. Maybe I’m doing something wrong?

could you share the code that you are using to wrap the code and log the stack trace?

Ok I double checked and you are right, it works for the Jobs, but for the Triggers I’m sure it shows some strange stack trace without my file reference. I’ll also check it once again.

I’d try to setup visual studio code to run parse server in debug mode so you’d be able to add a breakpoint for example.

1 Like

Ok, just checked and Jobs are good, but triggers gets me something like this:
ERROR ParseError: TypeError: Cannot read property ‘get’ of undefined
at error (/Workspace/parse-server/node_modules/parse-server/lib/triggers.js:381:16)
at processTicksAndRejections (node:internal/process/task_queues:93:5) {
code: 141
}

I’m not able to find the line in code easily without printing between the lines and trying to find the line code with the bug.

Here is just a basic sample.
I would just like to get code line number 9 in file Teams.js in the details of exception of the trigger but I’m getting:
at error (/Workspace/parse-server/node_modules/parse-server/lib/triggers.js:381:16)
at processTicksAndRejections (node:internal/process/task_queues:93:5)
So no reference to my code file and it’s hard to guess where the problem is if there is many more lines of code in the trigger. I think I’m going to remove all the triggers code and create cloud functions because it seems to be very hard to maintain in case of errors.

I believe you should have the error logged twice in your console. The first one in the way you expect to be and the other that you shared. If you remove the line 12, what do you have logged in your console?

I’m only rethrowing it - If I wouldn’t do it then the record would be saved and I don’t want it to be saved if I throw an exception. Besides it’s not related.

It is only a test that I’m asking you to do. In fact, you should see both logs. Also, try to use request.log instead of console.log.

What version of Parse Server are you running?

After 4.4.0, you should be able to see a trace if a JS error is thrown (such as a syntax error).

See this PR.

Also, it might help your tracing to throw using:

throw new Parse.Error('Error')

or

throw new Error('Error')
1 Like

Thanks, man!
throw new Parse.Error(‘Error’) worked as a charm.
Big kudos!

No worries! As for the cloud stuff - according to @dplewis in the PR I made around the tracing improvements, it might be easier to trace using directAccess: true

Yes @avramo, in NodeJs throwing an error without new Error() do not retrieve error context (like stack trace) :slight_smile:

Thanks @dblythy

I really wouldn’t expect that debugging in Visual Studio is possible, you saved tons of my time in the future.