supabase / cli / 28879195408
65%
develop: 65%

LAST BUILD BRANCH: gh-readonly-queue/develop/pr-5882-338321430422d32d2de30903a6af5047ec67a35a
DEFAULT BRANCH: develop
Ran
Jobs 1
Files 229
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 65.064%. Remained the same
28879195408

push

github

web-flow 
fix(cli): telemetry enable/disable fire cli_command_executed on pre-toggle consent (#5798)

## What kind of change does this PR introduce?

Bug fix (Go parity).

## What is the current behavior?

Go's `cli_command_executed` telemetry event is gated on a consent
snapshot read once at process start (`PersistentPreRunE`,
`apps/cli-go/cmd/root.go:131-138`), before a command's own handler runs,
and fired after the handler completes (`:171-181`) based on that
snapshot — not on any value the handler itself just wrote. This applies
uniformly to every command, including `telemetry enable`/`disable`
themselves.

The TS legacy port instead unconditionally suppressed this event for
both `telemetry enable` and `telemetry disable` via `analytics: false`,
so neither command ever fired it, regardless of prior telemetry state.

## What is the new behavior?

`analytics: false` is removed from both commands. The existing
`legacyAnalyticsLayer`/`telemetryRuntimeLayer` machinery already reads
consent from disk once, at Effect layer-construction time — before
either handler mutates `telemetry.json` — so this reproduces Go's
snapshot semantics without any new bespoke logic:

- Running `disable` while telemetry is enabled fires the event one last
time (using the pre-toggle, still-enabled snapshot); running it while
already disabled stays silent.
- Running `enable` while telemetry is already enabled (a
redundant/idempotent invocation) fires the event; the common case
(enabling from disabled) stays silent.

This is intentionally broader than the original report's "disable only"
framing — tracing Go's actual gate (`internal/telemetry/service.go`'s
`canSend()`) showed it's symmetric and state-based, not command-based,
so scoping the fix to `disable` alone would have left a real (if narrow)
parity gap for the redundant-`enable` case.

Also documents a previously-unmentioned side effect: when the event
fires, the command now waits (bounded, ~5s) for a PostHog flush attempt
before ... (continued)

11139 of 17120 relevant lines covered (65.06%)

10.49 hits per line

Coverage Regressions

Lines Coverage ∆ File
2
82.41
 0.0% internal/storage/rm/rm.go
Jobs
ID Job ID Ran Files Coverage
1 28879195408.1 229
65.06
 GitHub Action Run
Source Files on build 28879195408