Repository navigation
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. |
![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: 207404a8b7
ℹ️ 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".
| const result = await withPluginUse( | ||
| deps, | ||
| id, | ||
| currentTelemetryTrigger(), |
There was a problem hiding this comment.
When an action RPC is called from a plugin UI through useRpc, callPluginRpc in apps/app/src/lib/plugin-sdk-hooks.ts uses raw fetch and sends no app-surface header. The request is consequently classified as the API surface, so currentTelemetryTrigger() records the primary human interaction as trigger: "unknown" and telemetry also reports app_surface: "api" instead of person/web (or desktop/mobile). Route these calls through the app-surface-aware fetch boundary before deriving the trigger.
Useful? React with 👍 / 👎.
| pages: { input: ownedSchema, output: outputSchema }, | ||
| screenshot: { input: screenshotSchema, output: outputSchema }, | ||
| screenshot: { | ||
| experimental_usage: "action", |
There was a problem hiding this comment.
The selective classification here marks screenshot and stop, but the same public contract leaves the mutating open, run, and close methods unclassified. Direct client/SDK calls to those methods therefore produce no browser feature_used event, leaving the new shared RPC boundary with incomplete coverage of Browser Automation's main actions.
Useful? React with 👍 / 👎.
| const result = await withPluginUse(deps, id, "unknown", () => | ||
| registration.run(argv, ctx), | ||
| ); |
There was a problem hiding this comment.
Wrapping the entire generated CLI runner records an invocation before it is known whether any action ran. Requests such as bb <plugin> --help, malformed arguments that only render an error, and read-only subcommands all increment feature_used, so routine discovery and mistakes inflate plugin usage. Capture after command parsing/execution with action-aware command metadata rather than at the registration-wide dispatch boundary.
Useful? React with 👍 / 👎.
4ce79da to
9a92061
Compare
9a92061 to
4bf84c4
Compare
4bf84c4 to
b910246
Compare
b910246 to
7bfa74f
Compare
|
This is an automated message. We have closed this pull request because it has been open for more than two weeks. |
Human comments
What was wrong
Plugin actions lacked shared capture boundaries, so usage could be counted inconsistently. Actor and source classifications also differed between events.
What changed
Stack order: #5947 → #5437 → #5477 → #5469 → #5470 → #5471 → #5472 → #5473 → #5439.
How you verified
Existing Plugin Guide comparison: before
41e9b51b0fa4545dbfd8eb5a1a8d6d0b027f79ea; after40972c5893b7dfdbbf427ea7b5673df9bd345c34. Captured at 2× density with the same fixture and light theme. These retain their original capture revisions.BB-Thread-ID: thr_a4mhd93zji
BB-Thread-ID: thr_nq42ntdw95
BB-Thread-ID: thr_k4ic49de34