feat(agents): instrument /code/agents page with analytics events#2747
Merged
Conversation
Add AGENTS_VIEWED and AGENTS_ACTION events mirroring the inbox-reports instrumentation. AGENTS_VIEWED fires once per visit via a new useTrackAgentsViewed hook; AGENTS_ACTION covers change_autostart_priority, open_mcp_servers, and run_setup_agent from ConfigureAgentsSection.
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
Contributor
Prompt To Fix All With AIFix the following 2 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 2
packages/ui/src/features/agents/hooks/useTrackAgentsViewed.ts:34-37
**`isLoading` guard fires on error, locking in bad analytics data**
When any of the three backing fetches fail (network error, 4xx, etc.), the react-query `isPending`/`isLoading` flag drops to `false` even though data was never successfully fetched. This hook then fires immediately with whatever default/stale values are present — e.g. `has_github_integration: false` even when the user does have GitHub connected — and `firedRef.current` becomes `true`, so the event can never re-fire for the rest of that component lifetime.
`useTrackInboxViewed` (which this is modeled on) explicitly chose `!isSuccess` over `!isLoading` with a comment explaining exactly this failure mode. The input contract here would need a corresponding `isSuccess: boolean` (or `isError: boolean`) field passed from the caller alongside the combined loading flag, similar to how react-query's `isSuccess` is threaded through in the inbox hook.
### Issue 2 of 2
packages/ui/src/features/inbox/components/ConfigureAgentsSection.tsx:355-362
**`run_setup_agent` tracked twice when `result.success` is `true`**
The `track(AGENTS_ACTION, { action_type: "run_setup_agent", success: result.success })` call at line 358 fires unconditionally on every non-throwing `createTask` response, including the success path. The immediately-following `if (result.success)` block then also fires `TASK_CREATED`. This is fine, but note that because both the `try` path (line 358) and the `catch` path (line 384) call the same `run_setup_agent` event, a throw will produce exactly one event — but a `result.success === false` (non-throwing failure from `createTask`) will also produce exactly one event. The duplication risk is only if someone later wraps the `TASK_CREATED` call and assumes `AGENTS_ACTION` already fired; the current code is correct, but it may be cleaner to guard the line-358 call with `if (!result.success)` so the catch block's event stays as the sole failure-path emitter and the success path is covered by the existing `TASK_CREATED` event already fired.
Reviews (1): Last reviewed commit: "feat(agents): instrument /code/agents pa..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fd3864f097
ℹ️ 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".
Addresses review: an errored integrations fetch also clears isLoading, so the previous gate could fire AGENTS_VIEWED with default values (e.g. has_github_integration: false) and lock firedRef, preventing a correct re-fire after refetch. Add an isError gate (sourced from the integrations query) mirroring the !isSuccess gate in useTrackInboxViewed.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7f11b0d782
ℹ️ 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".
Addresses Codex review on the analytics PR: - has_github_integration: derive from the integrations query data instead of the store-backed value, which is hydrated by a passive effect that lags the query by a render and could lock in a stale false on the settle render. - responder counts: count only RESPONDER_AGENT_GROUPS sources; displayValues also carries the legacy signals_scout toggle, which renders separately and was inflating responder_total_count / responder_enabled_count. - run_setup_agent: emit success:false at the precondition guards (missing github/repo/region/user-integration, unresolved model) so failed setup attempts stay in the funnel instead of biasing the success rate upward.
andrewm4894
added
the
Stamphog
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pure analytics instrumentation — new event types, a once-per-visit view hook with proper error/loading guards, and action tracking calls. All inline review concerns were addressed in follow-up commits that are present in the current diff; no unresolved substantive issues remain.
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
1 participant
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.
What
Adds product analytics to the
/code/agentsconfiguration page, mirroring the inbox-reports instrumentation pattern (INBOX_VIEWED/INBOX_REPORT_ACTION).Two events:
Agents viewed— fires once per visit via a newuseTrackAgentsViewedhook (modeled onuseTrackInboxViewed), after responder/integration/autonomy data settles. Captures GitHub-integration state, responder total/enabled counts, the user's auto-start priority threshold, and whether the setup-task entry point is shown.Agents action— covers three interactions fromConfigureAgentsSection:change_autostart_priority(with new threshold)open_mcp_serversrun_setup_agent(with success)Files
packages/shared/src/analytics-events.ts—AGENTS_VIEWED/AGENTS_ACTIONevent names, property interfaces, andEventPropertyMapentriespackages/ui/src/features/agents/hooks/useTrackAgentsViewed.ts— new view-tracking hookpackages/ui/src/features/inbox/components/ConfigureAgentsSection.tsx— mounts the hook and firesAGENTS_ACTIONNotes
This complements the already-shipped scout instrumentation (
Scout fleet viewed,Scout action, etc.). Once merged and shipped, these events will flow into project 2 alongside the scout events.Testing
pnpm typecheckpasses (run by pre-commit hook)