[so0k]

Restores the per-stack signal the HashiCorp transport used to carry (backend, providers, overrides) as counted Sentry metrics, and reports what get and init generate. Volume is bounded per run: metrics are aggregated into counters with caps, never one event per stack or provider. Part of #48.

What changes

• sendStackTelemetry reduces each stack's metadata block and required_providers to enumerated values and counts; stack names, resource ids and addresses never enter a metric. Providers are public-registry namespace/type; other hosts become private-registry, malformed input other. Modules reduce to local, git, private-registry, other or a public registry address.
• Aggregation: one event per distinct identity, value = stacks sharing it, count attributes summed over the group. Caps: 8 stack groups, 32 provider tuples, 32 override types, 32 get/init sources. The most counted are kept; the rest fold into one event per metric with truncated: true, no identity attributes and the folded sum as value, so totals hold. A run sends at most 75 stack events.
• One stack block per process: a synth nested in another command sends only cli.synth.duration; deploy/destroy report the stacks they selected, diff the one diffed stack. So watch reports its first deploy only, output and list send no stack block, counts are project-level (stacks using a provider), and stacks cannot be correlated.
• diff, deploy and destroy send the stack metrics whether the Terraform operation resolves or rejects, then rethrow the original error; a failed send never replaces it. That includes a failed Terraform init. The failure itself is counted once as cli.command.error, and a run that failed is never counted as cli.command.completed, even with zero errored stacks.
• Per-command scalars ride on cli.command.completed through a typed allow-list; nothing else is forwarded. provider/binding are classified against terraformProviders read at command start.

Metric	When emitted	Attributes (plus base)
cli.stack	per distinct group of synth/diff/deploy/destroy	backend (enumerated, other, unknown), cloud, library_version, override_count, import_count, moved_count (sums), truncated
cli.stack.provider	per distinct provider tuple; value = stacks requiring it	provider, version_constraint (canonical or invalid), binding (generated/prebuilt), truncated
cli.stack.override	per distinct resource type; value = stacks overriding it	resource_type (grammar, 64-char cap, module.<kind>, else other), override_count (total paths), truncated
cli.stack.failed	when at least one stack errored; value = stacks whose Terraform operation errored. Stacks that never started are not counted, and a failed init counts none	base only
cli.get.provider, cli.get.module	per distinct generated binding source; value = entries	provider / module, truncated
cli.init.provider	per distinct provider passed to init	provider, truncated
scalars on cli.command.completed	per run	synth synth_origin (watch); init template (built-in name or remote), is_remote, provider_count; convert module_count, provider_count, converted_lines; get provider_count, module_count

Testing

• Unit: normaliser tables (provider and module sources, backends, constraints, resource types, identity length caps); aggregation values, tie order, residual truncated events with conserved totals, and tolerance of malformed entries.
• Unit with a real v10 client: the delivered stack, get and init metrics carry only the documented attributes; raw-envelope LEAK-* markers prove no name, host or path is sent.
• Failed runs are driven through real stack executors against a Terraform stub that rejects, not hand-set state: a rejected plan, apply or destroy yields the stack metrics and cli.stack.failed, then the original error and no cli.command.completed; a rejected init (diff, deploy, destroy) yields the stack metrics with no failed count.
• One stack errors while another never starts (parallelism: 1, and a failing stack with a dependant; deploy and destroy): cli.stack 2, cli.stack.failed 1, no cli.command.completed, the original error propagates.
• The bundle-level aggregation check is the e2e in fix(cli): resolve bundled handlers next to the entrypoint #414.

Stack: 5 of 6 — #409 → #410 → #411 → #412 → #413 → #414

[jsteinich]

Reviewed as part of the full tele/s1–tele/s6 stack. The privacy normalisers are the strongest part of this PR — normalizeProviderSource reducing non-public hosts to private-registry, classifyModuleSource collapsing anything path- or host-shaped, and groupSizes sending counts where the raw structure would carry resource ids. Collapsing four copies of the JSON.parse(stack.content)["//"].metadata incantation into SynthStack.telemetryPayload (with a try/catch, which the originals lacked) is a good catch too.

Four things.

1. cli.command.invoked means two different things depending on the command

finishStackRun (cdktf-project.ts:439) sends telemetry before throwing, so a failed deploy / diff / destroy emits both cli.command.invoked and cli.command.error. A failed synth exits inside synth-stack.ts (:181, :203, introduced in #411) and emits only cli.command.error, never invoked.

So invoked counts attempts for the stack commands and successes for synth. Any success-rate or funnel query across commands silently returns the wrong number, and it's the kind of thing that's very hard to notice once the data is in Sentry.

Worth picking one semantic and stating it in a comment next to the metric. Emitting invoked unconditionally at command start — and letting cli.command.error be the thing that varies — is the version I'd argue for: it makes error / invoked a real success rate, and it stops the meaning of invoked depending on which exit path a command happens to take.

2. Per-run metric volume is unbounded

sendStackTelemetry emits, per stack, one cli.stack + one cli.stack.override per resource type + one cli.stack.provider per provider; sendGetTelemetry emits one per generated binding. A 50-stack project with 10 providers each produces on the order of 550 metric events for a single cdktn deploy, each carrying ~12 attributes after #412's os / arch / binary / target_* additions. There's no cap anywhere.

Every individual attribute is bounded (that's the good part), but the number of emissions scales with project size, and Sentry bills per metric. Worth a sanity check against the plan's quota with a realistically large project before this ships — a cap, or aggregating the per-provider counts into the cli.stack metric rather than emitting one event each, would both bound it.

3. SYNTH_ORIGINS duplicates a type that could just move to commons

telemetry.ts:379:

// The synth origins the CLI passes through; see SynthOrigin in cli-core.
const SYNTH_ORIGINS = ["watch"];

The comment acknowledges the drift risk, on the premise that commons can't import cli-core. But the dependency only needs to go the other way: @cdktn/cli-core already depends on @cdktn/commons, commons doesn't depend on cli-core, and SynthOrigin is not exported from cli-core's public lib/index.ts (only SynthesizedStack is). So it's internal to lib/ and can move for free.

Make commons the source of truth and derive the type from the runtime array, so the allow-list and the type physically cannot drift:

// packages/@cdktn/commons/src/telemetry.ts
export const SYNTH_ORIGINS = ["watch"] as const;
export type SynthOrigin = (typeof SYNTH_ORIGINS)[number];

// packages/@cdktn/cli-core/src/lib/synth-stack.ts
export type { SynthOrigin } from "@cdktn/commons";

That leaves the four existing SynthOrigin references in synth-stack.ts and cdktf-project.ts working unchanged. One adjustment needed: ScalarAttribute.values is string[] at telemetry.ts:387 and won't accept a readonly tuple — widen it to readonly string[].

WATCH_EVENTS is a different case and I'd leave it: watch.ts:184 passes a bare { event: "start" } literal with no named type, so there's nothing being duplicated. If you want the same guarantee there it means introducing a WatchEvent type in commons and typing the call site against it, which is new work rather than de-duplication.

4. getGeneratedProviderSources() defaults to process.cwd()

telemetry.ts:470, inside sendStackTelemetry. Everything else that reads project state is deliberately captured at command start precisely because convert chdirs — usageTelemetryEnabledState and projectTargetAttributes both go through setX/getX pairs for exactly this reason. This one reads the cwd at emission time.

Harmless today (the stack commands don't chdir), so this is a consistency point rather than a bug — but it's the one reader that would silently do the wrong thing if a future command adopts the convert pattern, and the surrounding code has already established the safer idiom.

[so0k]

Item 1 is resolved in #411 rather than here, since that is where the divergence starts: cli.command.invoked is now emitted exactly once per run at command start, so it counts attempts for every command, a successful run ends with a single cli.command.completed carrying the scalars only known at the end, and a failed run ends with a single cli.command.error. That makes error / invoked a real failure rate across commands, and it means finishStackRun no longer emits the command metric before throwing: a failed deploy counts as one invoked at start and one error from the reporter, and a self-exiting synth failure counts under the command the run was started as. Items 2 to 4 are being addressed in this PR's own round.

[so0k]

@jsteinich items 2 to 4 are done, and the description is rewritten for the new shape. The title changed with it, since events are no longer per stack.

2. Unbounded volume. It was worse than the 550 you estimated: a deploy without --skip-synth sent the stack block twice (once from the nested synth, once from finishStackRun), and watch re-sent it on every iteration. Fixed in 3e3d36d by aggregating per run instead of capping a per-stack stream:

• cli.stack: one event per distinct (backend, cloud, library_version), value = stacks in the group, counts summed.
• cli.stack.provider: one per distinct (provider, version_constraint, binding), value = stacks requiring it.
• cli.stack.override: one per distinct resource_type.
• cli.get.* and cli.init.provider dedupe the same way.
• Caps of 8 stack groups, 32 provider tuples and 32 override types. The most counted are kept; the rest fold into one event per metric with truncated: true, no identity attributes, and the folded sum as its value, so totals are conserved.
• One block per process: a nested synth sends only cli.synth.duration.

Events per deploy	before	now
1 stack, 2 providers	9	6
50 stacks × 8 providers	1,103	14
300 stacks × 8 providers	8,403	17

Consequences, all intended: watch reports its first iteration only; output and list send no stack block; counts are project-level ("stacks using this provider"), so a single stack's backend can no longer be correlated with its providers. Aggregation keys on the normalised identity, so two different private registry hosts become one private-registry event with value 2, and a test asserts neither hostname is in the envelope bytes.

Also fixed while there: diff reported every stack although one is diffed (44b904b).

3. SYNTH_ORIGINS. Commons exports it as const with the derived SynthOrigin; cli-core imports the type, and the second declaration and its drift comment are gone (f7b7af1). ScalarAttribute.values is readonly string[].

4. getGeneratedProviderSources() read process.cwd() at emission. It is now captured at command start in the same store as the consent decision, language and targets (same commit). A test starts in one project, changes directory into another with different generated providers, and the classification does not move. One consequence: a long watch session classifies against the list from when it started.

Tests. The audit against the new test-audit skill found privacy guards with no test: removing the 64-character limit on version constraints passed everything, as did removing the git::/hg::/s3::/gcs:: branch of module-source classification. Both have rows now. The normaliser tables run through the delivered metric instead of calling the functions directly, which let six functions stop being public exports of commons. The stack, get and init metrics assert their exact attribute key sets.

[so0k]

Failed Terraform runs skip the stack telemetry they are meant to count

Found by Lumen's delta review at cc561198e and confirmed against the code.

The problem

In packages/@cdktn/cli-core/src/lib/cdktf-project.ts, finishStackRun() is only reached when the Terraform operation resolves:

• diff() awaits stack.diff() at :415; its catch throws Errors.External(...) at :416-420, before finishStackRun() at :422.
• deploy() awaits execute() at :539 and calls finishStackRun() only at :541.
• destroy() awaits execute() at :601 and calls finishStackRun() only at :603.

And a real failure always rejects: CdktfStack.run() records the stack as errored and then rethrows (cdktf-stack.ts:377-385), and execute() propagates the rejection (:490-510).

So for an ordinary failed plan, apply or destroy, the method exits before finishStackRun() runs.

How it shows up

cli.command.error is still counted by the command-level reporter, so nothing looks broken. But for exactly the runs they exist to describe, these are never emitted:

• cli.stack.failed
• the stack aggregate for the run
• the provider and override aggregates

The failed-stack metric will read near zero indefinitely. The comment above finishStackRun ("Reports before throwing, so a failed run still sends its stack metrics") describes the intent, not the behaviour, and the stack.error ? [...] : [] branch in diff() is only reachable if diff() resolves with an error set, which the production path does not do.

Why the tests pass

cdktf-project-telemetry.test.ts models failure synthetically:

• deploy/destroy mock execute() as resolving (:53) while the executor state is set by hand;
• diff uses a resolving diff() mock with an independently populated error.

Neither exercises a rejected Terraform operation, which is the only way a failure happens in production.

Fix (Lumen's suggestion)

Catch the operation's rejection, emit the stack telemetry from the executors' resulting states, then rethrow the original error:

• diff(): on rejection, report with the stack as failed, then throw the same Errors.External as today.
• deploy() / destroy(): wrap execute(); on rejection, derive the failed stacks from stacksToRun (the errored executors), report, then rethrow what execute() threw.

Telemetry must stay best-effort on this path: finishStackRun already swallows a failed send, and that has to hold here too so a telemetry problem can never replace the Terraform error the user sees. Take care not to double-report when the operation resolves and finishStackRun then throws its own failure.

Tests to add

• diff() where stack.diff() rejects: assert the stack metrics are sent with failedStackCount: 1 and the original error still propagates.
• deploy() and destroy() where execute() rejects: same assertions, including a multi-stack case where one stack fails and another succeeds.

Unchanged

The rebase-compatibility parts of the review (package_manager propagation and the typescript-pnpm template assertion) had no findings.

[so0k]

The case I listed as not covered is now tested (5704c36), since #410 fixes the unobserved rejection in execute() that blocked it: one stack errors while another never starts, for deploy and destroy, gives cli.stack 2 and cli.stack.failed 1 with no cli.command.completed. Counting pending stacks as failed again fails all four.