Add async traces (aka "long stack traces"). Uncaught errors will have an async stack trace attached. It uses a singleton stack (linked list) to track the current context. There is little to no perf impact when tracing is disabled. There is a reasonable (imho!) performance cost when tracing is enabled: about 3-4x cpu hit on node 6, which seems completely worth it when you need it!
New Internal APIs
pushContext pushes a context onto the context stack
swapContext swaps in a new context stack, returning the previously-current one. This allows swapping in a new current context before running user code, and then swapping back to the previous one when the user code is done.
peekContext return the current context stack
A few others dealing with stack trace filtering and formatting. See the code.
New Public APIs
enableAsyncTraces() turns on tracing
disableAsyncTraces() turns off tracing (and drops whatever the current context stack holds)
NODE_ENV env var set to "development" or "test" will enable tracing
CREED_DEBUG env var set to any non-empty value will enable tracing. This allows forcing async traces to be enabled in production (when NODE_ENV=production, for example)
Todo
[x] Update README to include API for enabling/disabling (including NODE_ENV and CREED_DEBUG env vars)
Coverage remained the same at 100.0% when pulling 44d8fc4ce8eca7d4478d2b01c03e6cde753d5660 on add-async-trace into e931ce917802235d627b3eaf9ccc306b993ee522 on master.
Coverage remained the same at 100.0% when pulling 691b06be681a30f10e8dd695fe94db6e43affada on add-async-trace into 658c6dfec7f822bf7f943fe1c4cc90461e5c4b75 on master.
Coverage remained the same at 100.0% when pulling 39536a69838534f143ce67a6852157e92c08e78b on add-async-trace into 658c6dfec7f822bf7f943fe1c4cc90461e5c4b75 on master.
Coverage remained the same at 100.0% when pulling e0a477c96c5f7991a4aac7d880aa12f120c8c61f on add-async-trace into 658c6dfec7f822bf7f943fe1c4cc90461e5c4b75 on master.
Coverage remained the same at 100.0% when pulling 35c3dc641fe1de62c1344e80557053cc40fade1e on add-async-trace into 658c6dfec7f822bf7f943fe1c4cc90461e5c4b75 on master.
Coverage remained the same at 100.0% when pulling 8c069a3b716785f9d1b5d6a03f42789e0fb97c0a on add-async-trace into 658c6dfec7f822bf7f943fe1c4cc90461e5c4b75 on master.
Coverage remained the same at 100.0% when pulling d158370c9dcf508620f50971ebbed3ad6271b80e on add-async-trace into 658c6dfec7f822bf7f943fe1c4cc90461e5c4b75 on master.
Coverage remained the same at 100.0% when pulling 1fe86b28e4a90bde29ffde3f67b04e6182def3ee on add-async-trace into 658c6dfec7f822bf7f943fe1c4cc90461e5c4b75 on master.
Coverage remained the same at 100.0% when pulling 546b2177db6dda2a93d7b9b81136f6809fdc5a2b on add-async-trace into 658c6dfec7f822bf7f943fe1c4cc90461e5c4b75 on master.
Coverage remained the same at 100.0% when pulling 699fd7a6fee5f41833f98dccc8b6c0f285c70a6d on add-async-trace into 658c6dfec7f822bf7f943fe1c4cc90461e5c4b75 on master.
Add async traces (aka "long stack traces"). Uncaught errors will have an async stack trace attached. It uses a singleton stack (linked list) to track the current context. There is little to no perf impact when tracing is disabled. There is a reasonable (imho!) performance cost when tracing is enabled: about 3-4x cpu hit on node 6, which seems completely worth it when you need it!
New Internal APIs
pushContext
pushes a context onto the context stackswapContext
swaps in a new context stack, returning the previously-current one. This allows swapping in a new current context before running user code, and then swapping back to the previous one when the user code is done.peekContext
return the current context stackNew Public APIs
enableAsyncTraces()
turns on tracingdisableAsyncTraces()
turns off tracing (and drops whatever the current context stack holds)NODE_ENV
env var set to"development"
or"test"
will enable tracingCREED_DEBUG
env var set to any non-empty value will enable tracing. This allows forcing async traces to be enabled in production (whenNODE_ENV=production
, for example)Todo
NODE_ENV
andCREED_DEBUG
env vars)