-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code insights: Extend GraphQL schema to expose repositories that cause incomplete datapoints #62578
Comments
Seems useful! One question: can't we have multiple reasons? In particular, wouldn't there potentially be a different reason per incomplete repository? |
In theory yes. Currently we have only timeout and generic as reasons. From what I can see the code encourages adding new types when there are errors that we want to distinguish from each other. sourcegraph/cmd/frontend/internal/insights/resolvers/insight_series_resolver.go Lines 554 to 559 in d7dc2b9
sourcegraph/internal/insights/store/store.go Lines 875 to 879 in d7dc2b9
I feel like changing the shape of the incomplete datapoints and its sub-fields can become a rabbit-hole and would avoid going this route unless necessary. An alternative to satisfy the need to to isolate out repos could be an additional field next to the incomplete datapoints that just has a list of repos with problems. """
Status indicators for a specific series of insight data.
"""
type InsightSeriesStatus {
...
"""
Data points that are flagged terminally incomplete for this series.
"""
incompleteDatapoints: [IncompleteDatapointAlert!]!
repositoriesWithProblems: [String!]!
} Instead of a list of repo names, this could also be a more sophisticated list with error reasons and timestamps. |
For sourcegraph/sourcegraph#62295 This PR updates the documentation with more tips for very large repositories. There are difficulties with Code Insights where it may run for a while, and then tell the user that there were incomplete data points. This probably came from very large repositories not being able to compute reasonably fast. In addition to this documentation update I'm working on giving users more information about which repositories lead to incomplete datapoints: sourcegraph/sourcegraph#62578 --- @sourcegraph/search-platform I poked a bit at the search backend when gathering this info, and would like to get your input if it's accurate, and if there may be other improvements to make complex queries run faster on very large repos :) @mike-r-mclaughlin Could you review if this new info would be helpful for customers? I'm planning to expose the repositories that caused incomplete datapoints with sourcegraph/sourcegraph#62578. Then a customer can see which repository didn't compute, pick that one, optimize the query, and then run the big Code Insight again.
#62295 surfaced problems with debugging timeout and generic problems that lead to incomplete data points. The documentation says that the user should reduce the scope of the query, but we see that customers prefer to run queries over all of their repositories. I'm not sure how we would bisect repositories to exclude the problematic ones.
Our GraphQL schema for
TimeoutDatapointAlert
andGenericIncompleteDatapointAlert
contains the time and maybe a generic reason that something went wrong.We could help users that don't have access to logs by exposing the repository/repositories that caused problems.
Example:
As a next step we could surface this information in our UI, but including this info in our GraphQL should be a good start.
The text was updated successfully, but these errors were encountered: