Repository navigation
feat(cli): tag command telemetry with stack backend and OrioleDB - #6940
Merged
Merged
Conversation
Add `stack_backend` and `orioledb` to `cli_command_executed` so error rates can be split between the legacy and new stack runtimes and between OrioleDB and standard Postgres projects. `resolveStackBackend` now returns no backend for commands that `experimental.stack` does not route, so only routed commands carry `stack_backend`. A command-scoped attribute sink lets config resolution record `orioledb` from both backends, including stack-mode failures that reject OrioleDB. Also remove the unused `withCommandInstrumentation` wrapper and refresh the analytics doc to describe the current event shape. Closes CLI-2589 Closes CLI-2590 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Drop the major-version OrioleDB case already covered by the shared predicate's image tests, and keep the routing test name short enough to avoid reformatting the whole case. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🤖 AI Review
Both independent reviews were available. Their overlapping test findings merge into one confirmed minor issue. The telemetry-scope finding is refuted by trusted conventions and the cited command's image-selection code. No additional defects were established. Verification used code inspection; tests were not run because dependencies are absent.
Findings
| Severity | Location | Category | Sources | Claim |
|---|---|---|---|---|
| 🟡 MINOR | apps/cli/src/command-internal/db-config.toml-read.unit.test.ts:3445 |
test-isolation |
claude+codex | The new telemetry fixtures retain an inherited SUPABASE_DB_ORIOLEDB_VERSION when env is undefined, causing the PostgreSQL 17 'no version' case to fail with a valid nonempty ambient override. The defaults-only fallback also lacks a telemetry-omission assertion. |
Refuted findings (kept for transparency, not posted as review comments)
apps/cli/src/command-internal/db-config.toml-read.ts:1288(telemetry-accuracy): Recording OrioleDB selection after remote-overlay merging, with subsequent reads overwriting earlier values, weakens the documented guarantee that orioledb describes local config only.
Refuted: The merge and replacement mechanisms exist, but they do not establish the claimed violation. trusted/docs/adr/0020-config-naming-vocabulary.md:40 explicitly includes [remotes.*] in the local config document. In the cited services path, services.handler.ts:139-167 passes the same resolved majorVersion and orioledbVersion to resolveDbImage, so both recordings agree; lines 172-187 use that image for the local service listing. analytics.md:95 distinguishes configured values from the actual remote database. Last-write-wins alone does not demonstrate incorrect telemetry.
Stats
Claude findings: 2 · Codex findings: 1 · Confirmed: 1 · Refuted: 1 · Uncertain: 0
Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Add `stack_runtime` (docker, podman, or native) to `cli_command_executed` once a stack-backend command resolves its stack, so stack-backend error rates can be split by runtime. It is recorded where the runtime becomes known: runtime selection for new and shadow stacks, the project stack lookup for local database commands, and the stack target resolver. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
jgoux
approved these changes
Oct 1, 2026
Both read config only through loadLocalProjectContext, so their events never carried orioledb. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
TL;DR:
cli_command_executednow records which local backend a command ran on (stack_backend:legacyorstack), which runtime its stack uses (stack_runtime:docker,podman, ornative), and whether the project selects an OrioleDB image (orioledb). With these, error rates can be compared per command between the legacy and new stack backends (and per container or native runtime), and between OrioleDB and standard Postgres projects, before the new stack becomes the default.Before
After
flowchart LR A["supabase <command>"] --> B{"routed by<br/>experimental.stack?"} B -->|yes| C["StackBackendContext<br/>legacy or stack"] B -->|no| D["no backend"] C --> E["handler runs"] D --> E E --> F["config read records<br/>orioledb true/false"] E --> R["stack lookup records<br/>stack_runtime"] F --> G["cli_command_executed<br/>+ stack_backend<br/>+ orioledb<br/>+ stack_runtime"] R --> GWhy
Command telemetry had no way to tell whether a command ran on the new stack runtime or the legacy one, so we couldn't measure the new runtime's adoption or failure rate. It also couldn't separate OrioleDB projects from standard Postgres ones.
What changed
resolveStackBackendreturns no backend for commands thatexperimental.stackdoes not route (and for--version). The root command providesStackBackendContextonly when a backend was selected. Handlers still default to legacy, so routing behavior is unchanged.withCommandTelemetryaddsstack_backendwhen a backend was selected. It also provides a command-scoped attribute sink, so code below the handler can add properties to the command event.orioledbis recorded wherever local database config is resolved: the legacy config reader, Postgres image resolution, and stack config loading. The stack records it before rejecting OrioleDB, so failed stack starts on OrioleDB projects are attributed. The value describes local config only; it doesn't describe remote targets such as--linkedor--db-url.stack_runtimeis recorded where a stack-backend command learns its stack's runtime: runtime selection for new and shadow stacks, the project stack lookup used by local database commands, and the stack target resolver used bystackcommands. Commands without a single stack (stack-modeservices,stack stop --all) omit it.withCommandInstrumentationwrapper and the unusedflags_used/flag_valuescontext fields.docs/analytics.mdnow describes the current wrapper, event shape, flag redaction and base properties.Linked issue
Closes CLI-2589
Closes CLI-2590
🤖 Generated with Claude Code