Repository navigation
Record anonymous setup progress and outcome events - #5412
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 65885da2da
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ## `PluginBbSdk.system.experimental_recordTelemetryEvent` | ||
|
|
||
| `system.experimental_recordTelemetryEvent(event)` posts one anonymous product event to `POST /api/v1/system/telemetry/events`, which forwards it to the server's usage telemetry under the install's anonymous id and drops it when usage data sharing is off. The request schema is a strict allow-list of setup-guide events with fixed enum or boolean properties; anything else is rejected with 400. Core callers, all through `recordTelemetryEvent` in `apps/app/src/components/onboarding/onboarding-telemetry.ts`: the setup guide (`OnboardingFlow`). Stabilize after deciding whether third-party plugins may emit product events at all (and, if so, how events are namespaced per plugin and rate limited), then rename project-wide and remove this entry. |
There was a problem hiding this comment.
List every core telemetry caller in the audit
The audit says the setup guide is the only core caller and describes the schema as setup-guide-only, but NewThreadComposer.tsx also calls the same helper for the newly allowed new_thread_submit event. Update this entry to document that behavior and caller so the required API audit is complete and future stabilization work does not overlook the composer path.
AGENTS.md reference: AGENTS.md:L28-L28
Useful? React with 👍 / 👎.
| experimental_recordTelemetryEvent( | ||
| args: SystemRecordTelemetryEventArgs, | ||
| ): Promise<SystemRecordTelemetryEventResult>; |
There was a problem hiding this comment.
Register the new SDK method in the Plugin Guide
Adding experimental_recordTelemetryEvent makes it a public PluginBbSdk surface, but the bb-sdk apiSymbols inventory in plugins/plugin-api-docs/src/surfaces.ts does not include it. Add PluginBbSdk.system.experimental_recordTelemetryEvent there so the canonical Plugin Guide can discover and document the new method.
AGENTS.md reference: AGENTS.md:L30-L30
Useful? React with 👍 / 👎.
Human comments
What was wrong
Setup progress, agent readiness, sign-in results and rejected new-thread submissions were not observable in anonymous telemetry.
What changed
useSetupCompleteand the experimental SDK method, and update configuration documentation.Supersedes #5394. Independently based on main; no shared-component dependency.
How you verified
3bd09c3262585b764d77cca6761fc2328a21c3bd. Full CI also passed after retrying the Windows provider-replay job.Exact-head telemetry delivery QA
Chrome for Testing 154.0.8037.92 exercised the branch web app at
3bd09c3262585b764d77cca6761fc2328a21c3bdwith fresh app data, telemetry enabled and the real production-mode server sender.startedand onecancelledoutcome.409 provider_disabled; the draft remained intact.201, one accepted outcome and a real Claude Code reply of “OK”. Each submission emitted one started outcome.The default
0.0.0-devversion intentionally disables the sender. This pass used0.0.0-qa-onboarding-3bd09c3and a transport-only preload redirecting the unchanged capture body to a loopback sink. That version is not excluded by the dashboard's exact dev-version filter, so no test events were sent to PostHog. Product source and event handlers were unchanged.Growth analytics independently executed the reached/ready/signed-in/submitted HogQL query against PostHog with no errors or warnings. This establishes query/schema compatibility; new-event ingestion after release remains unverified. Completing a new provider authentication was outside this pass: the real attempt was cancelled, and submission used an already-ready provider.
Retained boundary checks and follow-up
The unchanged implementation retains earlier API checks accepting allowed enum/null values and rejecting unknown enums, identifying extra fields and free text. Earlier sign-in startup-failure coverage used fixtures and was not a delivery check. Known P2 follow-up: abandonment during pending sign-in startup may be counted as failed when terminal creation later rejects.
Fresh full-viewport screenshots compare merge base
d34a3d219193d37bf4bb31b6b345dd113800c3f1with exact head3bd09c3262585b764d77cca6761fc2328a21c3bd, using the same isolated fixture, routes and scroll anchors. Desktop: 1440 × 900 CSS pixels; phone: 390 × 844; both at 2×.The user approved the simplified disclosure screenshots at
3bd09c3via Growth. Merge approval remains separate.BB-Thread-ID: thr_gt5eeahuym
BB-Thread: Onboarding