telemetry(amazonq): attach stack trace in onCodeGeneration failures

[siakmun-aws]

Problem

To further find issues in onCodeGeneration, need to attach stack trace when sending metrics

Solution

Attach stack trace when sending metrics

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[justinmk3]

This is lacking an acceptable explanation of what the purpose is, and how it works. Did you test this with a production webpack'd build? Nodejs stacktraces in the production build are usually obfuscated.

The docstring of the function does not give useful insights.

The function is non-trivial, and has no test coverage.

Assuming the function works, it belongs in a core util module, not randomly in the middle of a feature module.

[siakmun-aws]

This is lacking an acceptable explanation of what the purpose is, and how it works. Did you test this with a production webpack'd build? Nodejs stacktraces in the production build are usually obfuscated.

The docstring of the function does not give useful insights.

The function is non-trivial, and has no test coverage.

Assuming the function works, it belongs in a core util module, not randomly in the middle of a feature module.

Here is some background on the purpose of this PR. The previous (main branch) client has been able to send telemetry in the event of code generation failure. However, any uncaught errors, either toolkit or runtime error etc., will only result in sending a "Fault" telemetry. We want to be able to diagnose such errors, and therefore the stack trace is needed. TS obfuscation is expected since non-toolkit errors such as runtime errors are not obfuscated. Uncaught toolkit error names are obfuscated, but through the function names (not obfuscated) in the stack trace combined with the code line number and toolkit version, the cause can still be identified.

Docstring: modified since last commit to give more details
Test: added
File place: changed to shared/error.ts

[justinmk3]

what is going on here? why was this new base class introduced? what is the intended meaning of "safe message" ?

[siakmun-aws]

Safe message means the error message is safe to send to telemetry (no critical information). This was introduced to allow error classes which extends it can be sent to telemetry with its error message.
But this PR is not ready yet, so I will draft it for now.

[justinmk3]

That doesn't sound like the right direction. We already have scrubNames

aws-toolkit-vscode/packages/core/src/shared/errors.ts

Line 378 in 7d5a339

export function scrubNames(s: string, username?: string) {

which removes PII from strings. And that is used by getTelemetryReasonDesc, which already is used automatically.

Adding new, special classes is not the right way to approach this.