Separate console taming and causal console

[mhofman]

Currently the causal console (consoleTaming: "safe") does a lot of magic. In particular it replaces error objects with the decorated error name, and separately calls console.debug with the stack and related errors and information (from assert.note), all as strings.

consoleTaming: "unsafe" is not appropriate because, some properties of the start console may reveal powers (e.g. the stdout stream in node). Furthermore because of #636, the override of Error.prototype.constructor causes node's inspect to fail and print confusing error info (#944).

I propose to separate console taming from the causal console and error restoring mechanisms. Console taming would wrap all initial console methods to leave a safe console object in compartments (as long as we trust the initial methods to not mutate the arguments). Console augmenting would have different levels:

• None: passes argument through without changing anything or making extra console calls. A virtualized console aware of SES can use the getStackString and other note inspection powers to detail and serialize the console calls as it wishes. E.g. a plugin for sentry.
• Minimal: recreate a new error object with a stack own property containing the untamed stack, an constructor own property to satisfy node's inspect, and potentially a cause own property to convey some of the causal capabilities of SES. We could also imagine adding a note or details own property with the details from assert.note. It would not do anything else beside substituting the tamed error objects for detailed ones.
• Causal: The current causal console logic which serializes errors and their details as multiple console calls.

[mhofman]

Also the causal console should be updated to natively support AggregateError and .cause

[erights]

I like the shape of this plan. Your idea to synthesize an unredacted error object from the redacted error + side info is superb. You should take it farther. The synthesized error should have an unredacted message.

[mhofman]

Related:

• #731