Skip to content

NEW @W-19150636@ - Add telemetry to Config command and command field …#2024

Merged
aruntyagiTutu merged 3 commits intodevfrom
feat/add-config-command-telemetry
Apr 21, 2026
Merged

NEW @W-19150636@ - Add telemetry to Config command and command field …#2024
aruntyagiTutu merged 3 commits intodevfrom
feat/add-config-command-telemetry

Conversation

@aruntyagiTutu
Copy link
Copy Markdown
Contributor

@aruntyagiTutu aruntyagiTutu commented Apr 13, 2026

…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
image

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

…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,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +172 to +177
this.dependencies.telemetryEmitter.emitTelemetry(Constants.TelemetrySource, Constants.TelemetryEventName, {
sfcaEvent: Constants.CliTelemetryEvents.ENGINE_SELECTION,
command: Constants.CliCommands.CONFIG,
engine: coreEngineName,
ruleCount: ruleSelection.getRulesFor(coreEngineName).length
});
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code flow does not seems to be in the path of the config cli command.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, sorry I got confused here with engine selection.

@aruntyagiTutu aruntyagiTutu merged commit bc86d58 into dev Apr 21, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants