Open tsharan opened 6 years ago
Any suggestions?
How is this issue not getting more traction? @tsharan and I can't be the only people with this problem. In my case, I'm not getting anything useful at all that lets me know what the problem is. This is not the first time I've noticed this in the last couple weeks. I'm in the process of migrating all of our tests to use the async/await pattern and I've run into this problem several times along the way. I've even tried setting the logLevel
to 'DEBUG'
and I'm still not getting anything more than the basic jasmine default timeout error. What am I missing? I feel like there is something I must not know about using async/await or more people would be complaining about this problem.
Here is my super useful stacktrace:
× should do something
- Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
at ontimeout (timers.js:386:11)
at tryOnTimeout (timers.js:250:5)
**************************************************
* Failures *
**************************************************
1) Smoke Tests - should do something
- Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
Executed 14 of 14 specs (1 FAILED) in 1 min 12 secs.
Thankfully, I was actively working on this test so I knew exactly what was wrong but if this test had failed as part of a deployment verification process, aside from the spec that actually failed, I wouldn't have a clue where to start looking .
Experience the same issue described by @tsharan. Browser.wait shortens the stack trace, so it is not useful any more for debug purpose.
For what it's worth, I think the way to get some stacktraces that are actually useful in this situation is to wrap everything in a try/catch block. I usually skip this part but it's technically the right way to use async/await. Once you catch the error you can just log it to the console to see something useful.
Try/catch definitely should be used. Though, it still doesn't solve the problem.
Referring to tsharan original samples. Stack trace shows reference to method doSearch from search-helper.ts
, but doesn't show reference to where it was called in Sample spec.
I think the solution is here: https://github.com/nodejs/node/issues/11865
Edit: Checked Node.js 12.4.0, but it did not solve the problem out of the box.
Try Error.stackTraceLimit = Infinity;
in your code. Works with Node.js 12.x.x
I've tried the Error.stackTraceLimit = Infinity;
solution but that didn't work for me, does anyone else still have this issue? or did anyone solve this using a different solution?
I'm using node 12.16.1
Stacktrace is not having the reference to actual file name from where the error is triggered for the protractor.
Protractor version: 5.1.2
configuration:
Sample spec:
search-helper.ts:
1. Stack Trace with browser.wait
2. If we comment browser.wait statement then the stacktrace is
Observe the 2nd stack trace, it has references to search-helper file but it's not there in the first stack trace. It's very important to have this reference in stack trace for debugging.