Skip to content
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

Prefer #select result set over other result sets #2395

Merged
merged 1 commit into from
May 2, 2023

Conversation

koesie10
Copy link
Member

@koesie10 koesie10 commented May 2, 2023

For @kind problem queries, it seems like the BQRS contains four result sets: edges, nodes, subpaths, and #select. The user is probably interested in the results of #select since that contains the direct result of the query. This changes the extraction of raw (BQRS) results to always prefer #select over any other result set. If it can't find a result set named #select, it will fall back to the first result set in the BQRS like before.

Checklist

  • CHANGELOG.md has been updated to incorporate all user visible changes made by this pull request.
  • Issues have been created for any UI or other user-facing changes made by this pull request.
  • [Maintainers only] If this pull request makes user-facing changes that require documentation changes, open a corresponding docs pull request in the github/codeql repo and add the ready-for-doc-review label there.

For `@kind problem` queries, it seems like the BQRS contains four
result sets: `edges`, `nodes`, `subpaths`, and `#select`. The user is
probably interested in the results of `#select` since that contains the
direct result of the query. This changes the extraction of raw (BQRS)
results to always prefer `#select` over any other result set. If it
can't find a result set named `#select`, it will fall back to the first
result set in the BQRS like before.
@koesie10 koesie10 added the secexp label May 2, 2023
@koesie10 koesie10 requested a review from a team as a code owner May 2, 2023 12:24
Copy link
Contributor

@charisk charisk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to me! Thanks for fixing.

@koesie10 koesie10 merged commit 14eb7ff into main May 2, 2023
@koesie10 koesie10 deleted the koesie10/bqrs-use-select branch May 2, 2023 13:51
@aibaars
Copy link
Contributor

aibaars commented May 2, 2023

This makes sense, however, would it be possible to change the compiler to ensure that "main" result is always the first? For example for @kind problem it could make sure the #select or the query predicate problems is first.

@koesie10
Copy link
Member Author

koesie10 commented May 2, 2023

This makes sense, however, would it be possible to change the compiler to ensure that "main" result is always the first? For example for @kind problem it could make sure the #select or the query predicate problems is first.

Is there a CodeQL CLI command to retrieve the main result set? There is a function in the extension codebase that returns the "default" result set name, but this is a static list of alerts, graph, and #select. I believe this is the only function we use for determining the result set for local queries. However, for MRVA queries, we would usually only have either interpreted (SARIF) results or BQRS results, but won't show the BQRS results if SARIF results are available. Therefore, for MRVA we only use #select as a preferred result set name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants