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

fix(queryEnhancements): data.search() should not ignore the strategy passed as parameter #8368

Conversation

ruanyl
Copy link
Member

@ruanyl ruanyl commented Sep 27, 2024

This is quick fix for the issue that the search strategy passed to data.search() API been completely ignored when query enhancement is enabled and the localStorage has a language preserved.

For example, selecting a language from discover language selector will make data.search() called with a specific strategy to use the language config stored in localStorage which is unexpected.

With this fix, language config is only used when search strategy is not passed explicitly.

Sharing my two cents:

  1. I think it's better the language is passed as a parameter to data.search() instead of reading directly from query string manager(which has default value from local storage that different feature could share the same value). I think data.search() needs to be UI/feature-agnostic
  2. I'm fine with having different search intercepters for different languages, but it seems the current intercepters(ppl & sql) does way too much than than an "intercepter" should. IMHO, a search intercepter will just intercepts the search params(input) and search response(output), and does things like error handling, validation, etc. But now it seems we're building the search query in the intercepter by reading from some global state: time fitter, aggregation, etc. Shouldn't this be done upfront and passed to data.search() as search params?

I may not have a full picture of the entire idea of query enhancement, and I'm open to any other ideas :)

Description

Issues Resolved

Screenshot

Testing the changes

Changelog

  • fix: data.search() should not ignore the strategy passed as parameter

Check List

  • All tests pass
    • yarn test:jest
    • yarn test:jest_integration
  • New functionality includes testing.
  • New functionality has been documented.
  • Update CHANGELOG.md
  • Commits are signed per the DCO using --signoff

…` passed as parameter

This is quick fix for the issue that the search strategy passed to
data.search() API been completely ignored when query enhancement is
enabled and the localStorage has a language preserved.

For example, selecting a language from discover language selector
will make data.search() called with a specific strategy to use the
language config stored in localStorage which is unexpected.

With this fix, language config is only used when search strategy is not
passed specifically.

Signed-off-by: Yulong Ruan <[email protected]>
Copy link
Contributor

❌ Empty Changelog Section

The Changelog section in your PR description is empty. Please add a valid changelog entry or entries. If you did add a changelog entry, check to make sure that it was not accidentally included inside the comment block in the Changelog section.

Copy link
Contributor

❌ Empty Changelog Section

The Changelog section in your PR description is empty. Please add a valid changelog entry or entries. If you did add a changelog entry, check to make sure that it was not accidentally included inside the comment block in the Changelog section.

Copy link

codecov bot commented Sep 27, 2024

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 60.92%. Comparing base (8691010) to head (1d01c5f).
Report is 164 commits behind head on main.

Files with missing lines Patch % Lines
src/plugins/data/public/search/search_service.ts 0.00% 1 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #8368   +/-   ##
=======================================
  Coverage   60.92%   60.92%           
=======================================
  Files        3749     3749           
  Lines       89021    89021           
  Branches    13899    13899           
=======================================
  Hits        54236    54236           
  Misses      31423    31423           
  Partials     3362     3362           
Flag Coverage Δ
Linux_1 28.85% <0.00%> (ø)
Linux_2 56.35% <ø> (ø)
Linux_3 37.76% <0.00%> (?)
Linux_4 29.94% <0.00%> (ø)
Windows_1 28.87% <0.00%> (ø)
Windows_2 56.30% <ø> (ø)
Windows_3 37.76% <0.00%> (-0.01%) ⬇️
Windows_4 29.94% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@kavilla kavilla added the discover for discover reinvent label Sep 30, 2024
@ashwin-pc
Copy link
Member

@AMoo-Miki @kavilla Can you review this?

@ruanyl Can you add details about why this is needed now?

@ashwin-pc
Copy link
Member

@ruanyl i dont this the interceptors do that much anymore. afaik the ppl search interceptor should only add the time field to the ppl query from the query state and nothign more. SQL should make no modifications to the query. Is this not whats happening? I agree with you that the inerceptor should not modify anything in the query. I think the time selector is the only exception here but i could be swayed there as well.

If this is true, do we still need your change?

@ruanyl
Copy link
Member Author

ruanyl commented Oct 1, 2024

@ashwin-pc You're right, that's true for sql interceptor. For ppl interceptor it adds time filter even when there is a time filter in the ppl query, for example, I have ppl like source=opensearch_dashboards_sample_data_ecommerce | where order_date >= TIMESTAMPADD(DAY, -2, NOW()) | stats COUNT()

The actually query send becomes this which adds the time range from the ui

source = opensearch_dashboards_sample_data_ecommerce  | where `order_date` >= '2024-10-01 00:04:35' and `order_date` <= '2024-10-01 00:19:35' | where order_date >= TIMESTAMPADD(DAY, -2, NOW()) | stats COUNT()

And also it seems it modifies the aggregation which I don't fully understand the reason, maybe it's the default aggregation based on the time range?

        aggsConfig.qs = {
          [key]: `${query.query} | stats count() by span(${query.dataset!.timeFieldName}, ${
            value[aggTypeKey].fixed_interval ??
            value[aggTypeKey].calendar_interval ??
            this.aggsService.calculateAutoTimeExpression({
              from: fromDate,
              to: toDate,
              mode: 'absolute',
            })
          })`,
        };

If this is true, do we still need your change?

We still need this change because this change is about the 1st point for the language selector. The issue that I'm having is I'm using another search strategy, but after I selected PPL or SQL on the discover page, because of the following code, it will always use what's selected(ppl or sql) on discover app even I'm on another app. And actually, it calls data.search(request, {strategy: "whatever_strategy"}) directly and has nothing to do with the language selected on discover app.

      if (isEnhancedEnabled) {
        const queryStringManager = getQueryService().queryString;
        const language = queryStringManager.getQuery().language;
        const languageConfig = queryStringManager.getLanguageService().getLanguage(language);
        queryStringManager.getLanguageService().setUiOverridesByUserQueryLanguage(language);

        if (languageConfig) {
          return languageConfig.search.search(request, options);
        }
      }

@ashwin-pc
Copy link
Member

I'll let @kavilla answer why we modify aggs. Based on my understanding, we shouldn't. Also adding the time filter even if we already have on in the query is intended behavior to be consistent. If the UI has a time filter, it makes more sense to apply it to the query than not because it simpler to reason that way. Optionally adding it to the query makes it harder to reason when the UI time filter is applied and when the query time filter is used.

As for the change you are making, it seems fine temporarily to unblock your usecase but long term the goal is to have a strategy per dataset type and a interceptor per language and this solution breaks that. @kavilla will do a post 2.18 review of the design since we'll have to consolidate all the recent changes we've been making to the search pipeline.

Copy link
Member

@joshuali925 joshuali925 left a comment

Choose a reason for hiding this comment

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

i briefly looked into this, the fix looks good, but how do we know the options.strategy is supposed to be used with the defaultSearchInteceptor but not the languageConfig.search interceptor?

@ashwin-pc
Copy link
Member

That was my concern as well.

@ruanyl
Copy link
Member Author

ruanyl commented Oct 3, 2024

i briefly looked into this, the fix looks good, but how do we know the options.strategy is supposed to be used with the defaultSearchInteceptor but not the languageConfig.search interceptor?

@ashwin-pc @joshuali925
Thanks for following up :)

Both the current sql_search_interceptor and ppl_search_interceptor don't "care" the options.strategy, they have it's own logic to "compute" the strategy internally:
For sql_search_interceptor:

    let strategy = datasetType === DATASET.S3 ? SEARCH_STRATEGY.SQL_ASYNC : SEARCH_STRATEGY.SQL;

    if (datasetType) {
      const datasetTypeConfig = this.queryService.queryString
        .getDatasetService()
        .getType(datasetType);
      strategy = datasetTypeConfig?.getSearchOptions?.().strategy ?? strategy;
    }

For ppl_search_interceptor:

    let strategy = SEARCH_STRATEGY.PPL;

    if (datasetType) {
      const datasetTypeConfig = this.queryService.queryString
        .getDatasetService()
        .getType(datasetType);
      strategy = datasetTypeConfig?.getSearchOptions?.().strategy ?? strategy;
    }

So this PR won't affect the existing two languageConfig interceptors. However, I'd say this PR is just a temporary workaround to fix the issue that the passed strategy been ignored. I believe we would need a throughly refactor on this.

Copy link
Member

@joshuali925 joshuali925 left a comment

Choose a reason for hiding this comment

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

i'm ok with this temporary workaround. i think it would be good to have some comments to call out that the framework now assumes all search interceptors from language configs do not use options.strategy and do expect options.strategy to be absent

@kavilla could you also take a look since you are more familiar with this part

@ruanyl ruanyl merged commit e077644 into opensearch-project:main Oct 4, 2024
72 of 74 checks passed
opensearch-trigger-bot bot pushed a commit that referenced this pull request Oct 4, 2024
…` passed as parameter (#8368)

* fix(queryEnhancements): data.search() should not ignore the `strategy` passed as parameter

This is quick fix for the issue that the search strategy passed to
data.search() API been completely ignored when query enhancement is
enabled and the localStorage has a language preserved.

For example, selecting a language from discover language selector
will make data.search() called with a specific strategy to use the
language config stored in localStorage which is unexpected.

With this fix, language config is only used when search strategy is not
passed specifically.

Signed-off-by: Yulong Ruan <[email protected]>

* Changeset file for PR #8368 created/updated

---------

Signed-off-by: Yulong Ruan <[email protected]>
Co-authored-by: opensearch-changeset-bot[bot] <154024398+opensearch-changeset-bot[bot]@users.noreply.github.com>
(cherry picked from commit e077644)
Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
SuZhou-Joe pushed a commit that referenced this pull request Oct 7, 2024
…` passed as parameter (#8368) (#8495)

* fix(queryEnhancements): data.search() should not ignore the `strategy` passed as parameter

This is quick fix for the issue that the search strategy passed to
data.search() API been completely ignored when query enhancement is
enabled and the localStorage has a language preserved.

For example, selecting a language from discover language selector
will make data.search() called with a specific strategy to use the
language config stored in localStorage which is unexpected.

With this fix, language config is only used when search strategy is not
passed specifically.



* Changeset file for PR #8368 created/updated

---------



(cherry picked from commit e077644)

Signed-off-by: Yulong Ruan <[email protected]>
Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: opensearch-changeset-bot[bot] <154024398+opensearch-changeset-bot[bot]@users.noreply.github.com>
@ananzh ananzh added the v2.18.0 label Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants