feat(seer): Stub inbound upsert_pr_metrics_summary RPC#116673
Draft
vaind wants to merge 2 commits into
Draft
Conversation
…summary RPCs
Add two accept-and-acknowledge handlers to the seer-rpc surface so the Seer
side has a real, signed endpoint to integrate against before the PR-metrics
storage and full logic land. Both validate the org-scoped repository (via
repository_service.get_repository) and the required payload fields, log
structured context, and return {"success": True}; the actual persistence is
left as in-code TODOs because the PullRequest extensions and the new
PullRequestAttribution / PullRequestMetrics tables land separately in CORE-200,
with the full handler logic following in M1/M2/M3.
PRs are identified externally by organization_id + repository_id + pr_number;
repository_id already pins the provider, so no separate provider field.
Refs CORE-201
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
github-actions
Bot
added
the
Scope: Backend
… covers PR creation register_pr_attribution turned out to be unnecessary. Seer already emits the existing seer.pr_created event (SentryAppEventType.SEER_PR_CREATED) when a run creates a PR, and its payload carries the PR id/number/url, repo, and run_id — everything the push RPC was meant to deliver. Sentry therefore already learns about Seer-created PRs over the existing webhook channel, so a dedicated push handler is redundant. The inbound seer-rpc surface for PR-metrics reduces to upsert_pr_metrics_summary, the judge-verdict callback, which has no alternative source. Refs CORE-201 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
vaind
changed the title
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.
Adds an inbound handler to the seer-rpc surface (next to
send_seer_webhook) so the Seer side has a real, signed endpoint to integrate against before the PR-metrics storage and full logic land. Part of the PR Merge Live Metrics project (M0).What this adds
upsert_pr_metrics_summary(organization_id, repository_id, pr_number, event_id, verdict, counters, refined_attribution_signals?)— Seer's judge-summary callback at PR close/merge, registered under a new "PR Merge Live Metrics" section inseer_method_registry.Behavior
This is intentionally a validate-and-acknowledge stub. The handler:
repository_service.get_repository(...)(IDOR-safe — returns "Repository not found" on mismatch or missing);{"success": True}(graceful{"success": False, "error": ...}on validation failure, matching thesend_seer_webhookcontract).Actual persistence is left as an in-code
TODO. ThePullRequestfield extensions and the newPullRequestAttribution/PullRequestMetricstables land separately in CORE-200 (in progress); the full write follows in M1/M3 (CW-1436).Note on the dropped
register_pr_attributionAn earlier revision of this PR also stubbed
register_pr_attribution(a push channel for Seer to report PRs it created). That was dropped: Seer already emits the existingseer.pr_createdevent (SentryAppEventType.SEER_PR_CREATED) on PR creation, carrying the PR id/number/url, repo, and run_id — so Sentry already learns about Seer-created PRs over the existing webhook channel and a dedicated push RPC is redundant. The inbound seer-rpc surface for this project is thereforeupsert_pr_metrics_summaryonly.🚧 Draft — holding until the model migration (CORE-200) lands, then the TODO becomes a real write.
Refs CORE-201