lukechilds/node - node - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Trevor Norris	062beb08df	async_hooks: don't abort unnecessarily * id values of -1 are allowed. They indicate that the id was never correctly assigned to the async resource. These will appear in any call graph, and will only be apparent to those using the async_hooks module, then reported in an issue. * ids < -1 are still not allowed and will cause the application to exit the process; because there is no scenario where this should ever happen. * Add asyncId range checks to emitAfterScript(). * Fix emitBeforeScript() range checks which should have been \|\| not &&. * Replace errors with entries in internal/errors. * Fix async_hooks tests that check for exceptions to match new internal/errors entries. NOTE: emit{Before,After,Destroy}() must continue to exit the process because in the case of an exception during hook execution the state of the application is unknowable. For example, an exception could cause a memory leak: const id_map = new Map(); before(id) { id_map.set(id, /* data object or similar */); }, after(id) { throw new Error('id never dies!'); id_map.delete(id); } Allowing a recoverable exception may also cause an abort because of a stack check in Environment::AsyncHooks::pop_ids() that verifies the async id and pop'd ids match. This case would be more difficult to debug than if fatalError() (lib/async_hooks.js) was called immediately. try { async_hooks.emitBefore(null, NaN); } catch (e) { } // do something async_hooks.emitAfter(5); It also allows an edge case where emitBefore() could be called twice and not have the pop_ids() CHECK fail: try { async_hooks.emitBefore(5, NaN); } catch (e) { } async_hooks.emitBefore(5); // do something async_hooks.emitAfter(5); There is the option of allowing mismatches in the stack and ignoring the check if no async hooks are enabled, but I don't believe going this far is necessary. PR-URL: https://github.com/nodejs/node/pull/14722 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Refael Ackermann <refack@gmail.com>	8 years ago
Andreas Madsen	0fd4c73e5c	async_hooks: fix default nextTick triggerAsyncId In the case where triggerAsyncId is null it should default to the current executionAsyncId. This worked but as a side-effect the resource object was changed too. This fix also makes the null check more strict. EmitInitS is not a documented API, thus there is no reason to be flexible in its input. Ref: https://github.com/nodejs/node/issues/13548#issuecomment-310985270 PR-URL: https://github.com/nodejs/node/pull/14026 Reviewed-By: Refael Ackermann <refack@gmail.com>	8 years ago
Andreas Madsen	de762b71f2	async_hooks: rename currentId and triggerId currentId is renamed to executionAsyncId triggerId is renamed to triggerAsyncId AsyncResource.triggerId is renamed to AsyncResource.triggerAsyncId AsyncHooksGetCurrentId is renamed to AsyncHooksGetExecutionAsyncId AsyncHooksGetTriggerId is renamed to AsyncHooksGetTriggerAsyncId PR-URL: https://github.com/nodejs/node/pull/13490 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Trevor Norris <trev.norris@gmail.com>	8 years ago
David Cai	35353a45fc	test: increase coverage of async_hooks PR-URL: https://github.com/nodejs/node/pull/13336 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Andreas Madsen <amwebdk@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com>	8 years ago