Repository navigation
ref(integrations): Separate SCM repository list metrics - #129183
Conversation
joseph-sentry
left a comment
There was a problem hiding this comment.
on the general approach it'd be cool if we could avoid piping through the parent interaction type through all the functions & instead use a context var so we set it in one place
just something to consider
|
That's true… maybe even as part of the lifecycle start we can just say to which feature this belongs… I'll adjust, thanks for the suggestion |
|
Updated the implementation so SCM lifecycle entry sets the active feature in a |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5a9ebe4. Configure here.
Prevent reused lifecycle objects from overwriting their active SCM interaction context. Refs SCM-304

Moves GitHub and GitHub Enterprise repository-list operations out of
integrations.slo.*and records one regular metric tagged by provider, parent feature, and bounded result. Parent attribution now flows through repository choices, search, linking and sync, and derived code mappings, keeping complete feature lifecycles authoritative while preserving operational drill-down. This advances SCM-304.