telemetry(dev): add tracking for empty path file scenario

[tverney]

Problem

When customer use workspaces to generate files, RTS and LLM cannot decide which folder to deliver the generated file. We're for now tracking how many times we reach for accountability and prioritization.

Solution

Add telemetry to count and save the conversationIds that reach this specific workspace usage.

PS: This is should only be included in VS Code since the Workspaces capability its only used here.

---

License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

This pull request modifies code in src/ but no tests were added/updated. Confirm whether tests should be added or ensure the PR description explains why tests are not required.

[justinmk3]

When customer use workspaces to generate files, RTS and LLM cannot decide which folder to deliver the generated file. We're for now tracking how many times we reach for accountability and prioritization.

I don't understand what this means, nor the explanation in aws/aws-toolkit-common#856 .

Can this not be a field added to an existing metric instead of a new metric?

[tverney]

When customer use workspaces to generate files, RTS and LLM cannot decide which folder to deliver the generated file. We're for now tracking how many times we reach for accountability and prioritization.

I don't understand what this means, nor the explanation in aws/aws-toolkit-common#856 .

Can this not be a field added to an existing metric instead of a new metric?

Well, @jpinkney-aws suggested adding a new generic metric because we currently don't have one for it. In essence, team wanna track a specific scenario that's reached in VS Code to understand the usage of it and proper prioritization by RTS.

[justinmk3]

suggested adding a new generic metric because we currently don't have one

Ok. But amazonq_trackScenarioCountUsage is rather specific. Why does it mention "count" in the name? If we want to attach other fields (besides the "count") for that scenario, then we would need a new metric...

why not name it amazonq_trackScenario ? But also, every metric tracks a "scenario" already, so adding this metric which has a scenario field seems questionable.

[tverney]

When customer use workspaces to generate files, RTS and LLM cannot decide which folder to deliver the generated file. We're for now tracking how many times we reach for accountability and prioritization.

I don't understand what this means, nor the explanation in aws/aws-toolkit-common#856 .

Can this not be a field added to an existing metric instead of a new metric?

Well, the count its because we want limit the telemetry to just count the number of times we reach a specific condition. It was specific before, however, it was suggested to amplify to something more generic, so now it's talking about a "scenario". We will not be doing more than just counting for the moment. If you like it better, we could call it amazonq_trackConditionCountUsage. I'm ok with either naming conventions its good for you, the goal here its just have metrics on a "specific" condition for us.

[justinmk3]

For reference: aws/aws-toolkit-common#856 (comment)

[tverney]

For reference: aws/aws-toolkit-common#856 (comment)

Updated there, thanks.

[justinmk3]

you may need to update the aws/telemetry package, or just merge in current master?

npm ERR! src/amazonqFeatureDev/session/sessionState.ts(80,23): error TS2339: Property 'toolkit_trackScenario' does not exist on type 'TelemetryTracer'.

[tverney]

you may need to update the aws/telemetry package, or just merge in current master?

npm ERR! src/amazonqFeatureDev/session/sessionState.ts(80,23): error TS2339: Property 'toolkit_trackScenario' does not exist on type 'TelemetryTracer'.

Let me merge/rebase it again