chore(scm-multi-platform-detetion): Adding metrics for single platform detector.#117060
Conversation
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit d78b905. Configure here.
|
|
||
| metrics.timing( | ||
| f"{_SINGLE_METRICS_PREFIX}.duration", | ||
| time.monotonic() - start_time, |
There was a problem hiding this comment.
Unclear to me if this should be passed to metrics.timing in seconds or ms? looks like both variants are used within the repo, might be worth investigating.
There was a problem hiding this comment.
@jaydgoss I switched over to sentry metrics, just more familiar with the querying UI. Passed the millisecond unit along
…int (#117094) Adds a measurement-only endpoint to size up the tree-based (multi-platform) detector before we build it, without touching the live detection path. **Why a separate endpoint**: it runs in parallel with the current detection request, fully off the live path, so it can't slow down or break onboarding. Faster revert, we just remove the FE call. It reuses the existing endpoint's guarding, makes a single recursive git tree call off HEAD, and returns 204 (no body). We call the GitHub client directly instead of `get_tree` because that helper hides the truncated flag, which we need. Metrics (onboarding-scm.platform_detection.multi): `duration`: tree fetch latency, to compare against the current detector. `completed`: counter of successful runs, tagged is_truncated to see how often GitHub truncates the tree. `tree.entry_count`: number of tree entries (repo size signal). `repo_size_bytes`: total blob bytes (compute/cost signal). On any GitHub error (incl. empty-repo 409) we log and bail without emitting completed, so failures don't skew the data. --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>
|
🚨 Warning: This pull request contains Frontend and Backend changes! It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently. Have questions? Please ask in the |
… the FE (#117113) Depends on: #117060 Documentation: https://app.notion.com/p/sentry/Sub-dir-Multi-Platform-Detection-Plan-3738b10e4b5d80b8a297d307e454db7f --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>
…m detector. (#117060) Adds Sentry metrics to the current single-platform detector `.single.duration` (timing) measures detector wall-time from the first GitHub call through ranking, emitted on successful completion. `.single.completed` (incr) counts detections and carries three tags: `confidence`: the top result's confidence, high / medium / none (high means a framework matched, medium means base-language fallback). `languages_count`: distinct Sentry base platforms across the repo's languages (SDK-less languages ignored, TypeScript+JavaScript collapsed to one), bucketed. This sizes how often repos are actually multi-platform even though today we only return the top one. `content_reads`: number of file-content API calls made, bucketed. Excludes the two fixed calls (languages + root listing). --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>
… the FE (#117113) Depends on: #117060 Documentation: https://app.notion.com/p/sentry/Sub-dir-Multi-Platform-Detection-Plan-3738b10e4b5d80b8a297d307e454db7f --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>

Adds Sentry metrics to the current single-platform detector
.single.duration(timing) measures detector wall-time from the first GitHub call through ranking, emitted on successful completion..single.completed(incr) counts detections and carries three tags:confidence: the top result's confidence, high / medium / none (high means a framework matched, medium means base-language fallback).languages_count: distinct Sentry base platforms across the repo's languages (SDK-less languages ignored, TypeScript+JavaScript collapsed to one), bucketed. This sizes how often repos are actually multi-platform even though today we only return the top one.content_reads: number of file-content API calls made, bucketed. Excludes the two fixed calls (languages + root listing).