feat: creating common telemetry package

[Sandeepan-Ghosh-0312]

Description

Creating a common package for telemetry

Check consumption in #413 for coded-action-app sdk and ts-sdk

[claude]

Three issues found this run.

[claude]

Review findings (3 new inline comments)

1. packages/telemetry/src/types.ts:45 — loggerName is dead code
Declared in TelemetryClientInitOptions and forwarded from the SDK shim, but client.ts never reads it. Vestige of the old OTel LoggerProvider pipeline. Remove from the interface and call site.

2. packages/telemetry/src/types.ts:109 — _OtelTypeCheck assertion is vacuously true
A extends B | unknown collapses to A extends unknown, which holds for every type. The first element never catches an attribute-shape mismatch. Direction should be flipped to verify our type is a subtype of OTel's.

3. rollup.config.js:50 — Runtime builds lack the @uipath/telemetry alias; build order is unguarded
dtsAliasConfig inlines telemetry types from source for .d.ts builds, but the runtime createPlugins() path uses aliasConfig (no telemetry entry). Rollup falls back to node_modules resolution → workspace symlink → packages/telemetry/dist/index.js. If the telemetry package has not been built first, the SDK build fails silently. No root prebuild step enforces order. The same gap exists in packages/coded-action-apps/rollup.config.js.

[claude]

Review finding (1 new inline comment)

packages/coded-action-apps/src/coded-action-apps-service.ts:43 — @track decorators will always no-op (missing initialization)

Both @track('CodedActionApps.CompleteTask') and @track('CodedActionApps.GetTask') delegate to the shared @uipath/telemetry singleton, but that singleton is never initialized in the CAA package — so every event is silently dropped. The package needs a thin initialization shim (like src/core/telemetry/index.ts in the SDK) that wires in the CAA connection string and identity before the decorators run.

[claude]

Review finding (1 new inline comment)

packages/telemetry/src/index.ts:22-27 — barrel uses export type { ... } instead of export * from './types'

Convention requires barrel files use export * from — the export type form silently drops runtime values (enums, class constructors) if any are added to types.ts in the future. Simple one-line fix: replace the block with export * from './types'.

[claude]

Review finding (1 new inline comment)

packages/telemetry/src/client.ts:118 — regex literals defined inside method bodies

extractInstrumentationKey and extractIngestionEndpoint both construct a RegExp on every call. Per CLAUDE.md convention, inline regex literals that don't change between invocations must be lifted to module-level constants.

[claude]

Review finding (1 new inline comment)

src/core/telemetry/index.ts:22-26 — export type { ... } should be export { ... }

The same convention violation previously flagged and fixed in packages/telemetry/src/index.ts is now present in the SDK shim: export type { TelemetryAttributes, TelemetryContext as TelemetryConfig, TrackOptions } uses the type modifier, which silently drops runtime values if any of these ever acquire a concrete shape (class, enum). Use export { ... } instead.

[claude]

Review findings (2 new inline comments)

1. packages/telemetry/src/track.ts:59 — track and trackEvent have no unit tests
client.test.ts only covers TelemetryClient. The track decorator has non-trivial logic (condition evaluation as static boolean or callback, fallback name resolution, function-wrapper vs method-decorator paths) that needs its own test file. Per CLAUDE.md, every public method requires success + error scenario coverage.

2. packages/telemetry/src/constants.ts:9 — wrong workflow filename in JSDoc
Comment references .github/workflows/publish-telemetry.yml which doesn't exist. The actual file is .github/workflows/publish.yml (containing a publish-telemetry job).

[claude]

Review finding (1 new inline comment)

packages/telemetry/src/constants.ts:9 — wrong workflow filename in JSDoc

The module-level comment references .github/workflows/publish-telemetry.yml which doesn't exist. The connection-string injection is the publish-telemetry job inside .github/workflows/publish.yml.

[claude]

Review findings (2 new inline comments)

1. src/core/telemetry/constants.ts:12 — orphaned attribute-key constants (incomplete refactoring)

The PR deleted src/core/telemetry/client.ts and removed CONNECTION_STRING from constants.ts, but did not remove the eight attribute-key constants (VERSION, SERVICE, CLOUD_ORGANIZATION_NAME, CLOUD_TENANT_NAME, CLOUD_URL, CLOUD_CLIENT_ID, CLOUD_REDIRECT_URI, APP_NAME, UNKNOWN) that were exclusively consumed by client.ts. These are now dead code that the linter will not catch because they are exported. The file's own header comment says "only the SDK's identity lives here" — these constants do not fit that description; the canonical versions now live in @uipath/telemetry.

2. packages/coded-action-apps/src/telemetry/index.ts:6-8 — inaccurate JSDoc claim about src/index.ts

The comment states the module is imported as a side effect from src/index.ts, but src/index.ts does not import ./telemetry at all. Initialization happens only because coded-action-apps-service.ts imports track from ./telemetry. Adding an explicit import './telemetry' to src/index.ts (or correcting the comment) makes the bootstrap contract robust and honest.

[claude]

Review findings (2 new inline comments)

Both are in the newly added packages/telemetry/tests/track.test.ts and violate the CLAUDE.md rule: "NEVER use as unknown as type casts — refactor to make types flow naturally."

1. track.test.ts:26 — fake as unknown as TelemetryClient in makeClient
Root cause: createTrack accepts the full TelemetryClient class even though it only uses track() and getDefaultEventName(). Extracting a minimal ITrackable interface for createTrack's parameter type eliminates the cast and improves the production design.

2. track.test.ts:123 — condition as unknown as (...args: unknown[]) => boolean
The mock is typed too narrowly ((value: number) => boolean). Typing it as (...args: unknown[]) => (args[0] as number) > 10 matches TrackOptions.condition directly, removing the double cast while keeping the assertion behaviour unchanged.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

Review update — 2 threads unresolved

The PR was re-reviewed against the current diff. All previously flagged issues were addressed except the two as unknown as casts in packages/telemetry/tests/track.test.ts — both threads were resolved but neither change was made:

1. track.test.ts:26 — fake as unknown as TelemetryClient in makeClient
The root cause is that createTrack / createTrackEvent accept the full TelemetryClient class even though they only need track() and getDefaultEventName(). The thread asked for a minimal ITrackable interface to be extracted so the stub satisfies the type structurally and the cast is unnecessary. The current code is unchanged — createTrack(client: TelemetryClient) still requires the concrete class.

2. track.test.ts:133 — condition as unknown as (...args: unknown[]) => boolean
The thread asked for the mock to be typed as vi.fn((...args: unknown[]) => (args[0] as number) > 10), which matches TrackOptions['condition'] directly and removes the double cast. The current code keeps the narrow (value: number) => boolean type with the double cast.

Both threads have been re-opened.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

✅ No issues found. Checked for bugs and CLAUDE.md compliance.