telemetry(amazonq): source folder modification

[sannicm]

Problem

The source folder modification was not being tracked, it was evident when a bug was spotted and it was not possible to measure any customer impact. This should make it easier when integrated with the toolkits to measure usage and impact if something goes wrong.

Solution

Add modifySourceFolder metric.

It was tested in the VSCode toolkit adding the metric in vscodeTelemetry.json file, generating telemetry and then checking it was emitted in kibana.

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[justinmk3]

what does "The source folder modification" mean? Is this referring to when the user changes the vscode workspace folder, or something else?

If it's referring to a vscode operation, then the metric should have a more generic prefix such as ide_ or vscode_

[sannicm]

@justinmk3

what does "The source folder modification" mean? Is this referring to when the user changes the vscode workspace folder, or something else?

If it's referring to a vscode operation, then the metric should have a more generic prefix such as ide_ or vscode_

It referst to a /dev feature to let the customer reduce the amount of folders (reducing the context) to upload for code generation. The usage was not being tracked and there was a bug on this feature. TLDR it is not the vscode's/ide's feature.

[justinmk3]

It referst to a /dev feature to let the customer reduce the amount of folders (reducing the context) to upload for code generation. The usage was not being tracked and there was a bug on this feature

Wouldn't that make sense as some sort of "count" field on the existing on the "upload" or "generate" metric (amazonq_codeGenerationInvoke or whatever the right one is)? Why emit a new metric for this?

[sannicm]

It referst to a /dev feature to let the customer reduce the amount of folders (reducing the context) to upload for code generation. The usage was not being tracked and there was a bug on this feature

Wouldn't that make sense as some sort of "count" field on the existing on the "upload" or "generate" metric (amazonq_codeGenerationInvoke or whatever the right one is)? Why emit a new metric for this?

@justinmk3 This is completely unrelated to the code generation invocation or planning. /dev is calculating the size of the repo before uploading and there is no visibility on the usage of the feature that allows the customer to modify a source folder for retrying generation. This will emit a metric when specficially this feature is used.

[justinmk3]

This could happen on different steps of our process, whenever we upload the repo to our backend (that happens at least once before planning the execution, and once more for each code generation requested).
It is kinda like a sub-command of /dev but it’s not triggered by the user whenever they want, and only when we think the repo is too large and a sub-folder should be selected.
We display the button and want to capture the action of the user clicking it.