NEW @W-19150636@ - Add telemetry to Config command and command field …#2024
NEW @W-19150636@ - Add telemetry to Config command and command field …#2024aruntyagiTutu merged 3 commits intodevfrom
Conversation
…to all CLI telemetry events - Added CliCommands constant with RUN, RULES, CONFIG values - Implemented full telemetry support in ConfigAction with TelemetryEventListener - Added 'command' field to all CLI telemetry events to distinguish between run/rules/config - Updated RunAction to include command field in ENGINE_SELECTION and ENGINE_EXECUTION events - Updated RulesAction to include command field in ENGINE_SELECTION events - Updated tests to expect the new command field in telemetry data
| } | ||
| this.dependencies.telemetryEmitter.emitTelemetry(Constants.TelemetrySource, Constants.TelemetryEventName, { | ||
| sfcaEvent: Constants.CliTelemetryEvents.ENGINE_SELECTION, | ||
| command: Constants.CliCommands.RUN, |
There was a problem hiding this comment.
Will we get 2 run command telemetry events for ENGINE_SELECTION and ENGINE_EXECUTION? If only the command is reflected in the pft events we will see 2 run metrics for one execution of the command and and since no sfcaEvent is there we will not be able to distinguish b/w the one for ENGINE_SELECTION and the one for ENGINE_EXECUTION. Is this expected behaviour?
There was a problem hiding this comment.
No, this is not a problem. The concern is based on a misunderstanding.
What's actually emitted:
For a single run command execution, you get 2 telemetry events per engine, and both events include BOTH the sfcaEvent and command fields:
Event 1 - ENGINE_SELECTION:
{
sfcaEvent: 'engine_selection', // ← Identifies this as selection event
command: 'run', // ← Identifies which command
engine: 'pmd',
ruleCount: 50
}
Event 2 - ENGINE_EXECUTION:
{
sfcaEvent: 'engine_execution', // ← Identifies this as execution event
command: 'run', // ← Identifies which command
engine: 'pmd',
violationCount: 10
}
Why you CAN distinguish them:
- The sfcaEvent field tells you whether it's engine_selection or engine_execution
- The command field tells you whether it came from run, rules, or config
This is expected and correct behavior:
- run command: emits ENGINE_SELECTION + ENGINE_EXECUTION (2 events per engine)
- rules command: emits ENGINE_SELECTION only (1 event per engine)
- config command: emits ENGINE_SELECTION only (1 event per engine)
The sfcaEvent field has always been there to distinguish between selection and execution. The new command field just adds another dimension to identify which CLI command was used.
| this.dependencies.telemetryEmitter.emitTelemetry(Constants.TelemetrySource, Constants.TelemetryEventName, { | ||
| sfcaEvent: Constants.CliTelemetryEvents.ENGINE_SELECTION, | ||
| command: Constants.CliCommands.CONFIG, | ||
| engine: coreEngineName, | ||
| ruleCount: ruleSelection.getRulesFor(coreEngineName).length | ||
| }); |
There was a problem hiding this comment.
This code flow does not seems to be in the path of the config cli command.
There was a problem hiding this comment.
in my understanding
This code is definitely in the execution path of the config CLI command. The ConfigAction.execute() method is the main entry point when running sf code-analyzer config, and emitEngineTelemetry() is called directly from within execute() after the rule selection
completes but before the method returns.
The config command performs rule selection internally (via userCore.selectRules()) to determine which rules will be included in the generated config file - this is the core functionality of the command. After the selection completes, we have the actual data about
which engines were selected and how many rules from each engine, so we emit telemetry at that point. This follows the same pattern as the run and rules commands - emit telemetry after you have the selection results.
There was a problem hiding this comment.
Makes sense, sorry I got confused here with engine selection.
…to all CLI telemetry events
SELECT
command,
sfcaEvent,
COUNT(*) as event_count,
COUNT(DISTINCT engine) as unique_engines,
AVG(CASE WHEN ruleCount IS NOT NULL THEN ruleCount END) as avg_rule_count,
AVG(CASE WHEN violationCount IS NOT NULL THEN violationCount END) as avg_violation_count
FROM telemetry_events
WHERE
eventName = 'plugin-code-analyzer'
AND source = 'CLI'
AND sfcaEvent IN ('engine_selection', 'engine_execution')
GROUP BY command, sfcaEvent
ORDER BY command, sfcaEvent
For a time-series visualization (events over time by command):
SELECT
DATE_TRUNC('day', timestamp) as date,
command,
COUNT(*) as event_count
FROM telemetry_events
WHERE
eventName = 'plugin-code-analyzer'
AND source = 'CLI'
AND timestamp >= NOW() - INTERVAL '30 days'
GROUP BY DATE_TRUNC('day', timestamp), command
ORDER BY date, command
For a simple count by command (tile metric):
SELECT
command,
COUNT(*) as total_events
FROM telemetry_events
WHERE
eventName = 'plugin-code-analyzer'
AND source = 'CLI'
AND timestamp >= NOW() - INTERVAL '7 days'
GROUP BY command