thefrontside / bigtest

Ensure your React/Vue/Ember/anything app works perfectly across browsers.
https://frontside.com/bigtest
99 stars 14 forks source link

Resolve sources in stack traces that are generated on remote JavaScript runtime #431

Closed cowboyd closed 4 years ago

cowboyd commented 4 years ago

We generate sourcemaps for each test bundle which means that in the browser where an exception occurs, the sources are resolved. However, when the same exception is transmitted across the network, logging it out to the console does not resolve the sources because

  1. it isn't an Error class
  2. the stack trace was generated by code on a remote JavaScript vm and so the sourcemap is not intrinsically associated with the code.

We need to first figure out how to do this period, possibly by manually loading the sourcemap, and and then figure out how to integrate it into our output.

Example

 AssertionError: expected 2 == 3
|       at _callee$ (http://localhost:24005/manifest-44d22a51a12a34996032ee8496870689be93fe591ea90818f31fe310be8dfdfc.js:66693:23)
|       at tryCatch (http://localhost:24005/manifest-44d22a51a12a34996032ee8496870689be93fe591ea90818f31fe310be8dfdfc.js:196:23)
|       at Generator.invoke [as _invoke] (http://localhost:24005/manifest-44d22a51a12a34996032ee8496870689be93fe591ea90818f31fe310be8dfdfc.js:413:28)
|       at Generator.next (http://localhost:24005/manifest-44d22a51a12a34996032ee8496870689be93fe591ea90818f31fe310be8dfdfc.js:249:27)
|       at asyncGeneratorStep (http://localhost:24005/manifest-44d22a51a12a34996032ee8496870689be93fe591ea90818f31fe310be8dfdfc.js:861:28)
|       at _next (http://localhost:24005/manifest-44d22a51a12a34996032ee8496870689be93fe591ea90818f31fe310be8dfdfc.js:883:13)
|       at http://localhost:24005/manifest-44d22a51a12a34996032ee8496870689be93fe591ea90818f31fe310be8dfdfc.js:890:11
|       at new Promise (<anonymous>)
|       at http://localhost:24005/manifest-44d22a51a12a34996032ee8496870689be93fe591ea90818f31fe310be8dfdfc.js:879:16
|       at _assertEqual (http://localhost:24005/manifest-44d22a51a12a34996032ee8496870689be93fe591ea90818f31fe310be8dfdfc.js:6670
taras commented 4 years ago

@cowboyd here is the thing that I was telling you about https://github.com/facebook/jest/tree/master/packages/jest-source-map

GitHub
facebook/jest
Delightful JavaScript Testing. Contribute to facebook/jest development by creating an account on GitHub.
cowboyd commented 4 years ago

Cool 😎 There may be some extra munging required since these callsites reference an http url, not a local file path

jnicklas commented 4 years ago

I've done some experimentation and research on this, trying to find a way to extract proper stack traces.

There are a few packages which enable/simplify this:

The big question is whether to perform the resolution in the agent or in the orchestrator. I can see arguments for both.

GitHub
stacktracejs/error-stack-parser
Extract meaning from JS Errors. Contribute to stacktracejs/error-stack-parser development by creating an account on GitHub.
GitHub
Build software better, together
GitHub is where people build software. More than 50 million people use GitHub to discover, fork, and contribute to over 100 million projects.
GitHub
Build software better, together
GitHub is where people build software. More than 50 million people use GitHub to discover, fork, and contribute to over 100 million projects.
GitHub
facebook/jest
Delightful JavaScript Testing. Contribute to facebook/jest development by creating an account on GitHub.
npm
source-map
Generates and consumes source maps
cowboyd commented 4 years ago

@jnicklas I vote for doing it in the agent since multi-platform agents are on the roadmap. Also, it just seems more sane long term to have the system that actually raised the error be responsible for providing metadata about it since there's no moment, like the moment you catch the error to capture information about it. The agents will always have the edge here.