Remove the partial-result opt-in from Explore, keep the warnings banner

[ahkcs]

Description

Companion to opensearch-project/sql#5814, which removes the engine-side opt-in partial-result mode for mapping conflicts (added in opensearch-project/sql#5657). This removes the Dashboards half added in #12481 — and keeps the warnings banner, which a different engine change still needs.

Why. The feature returned a knowingly incomplete aggregation to make a query faster: on a field mapped inconsistently across indices it aggregated over only the aggregatable subset and labelled the result. That is not a good default to offer, and the "Rerun without partial results" button implied a remedy that applied only to that one narrowing case — it does nothing for any other reason a result might be incomplete.

Removed

explore:enablePartialResults	advanced setting + its PARTIAL_RESULTS_SETTING constant
partial_result on the query	data/common/query/types.ts and the facet.ts passthrough. The PPL route schema still accepts it and drops it, since older Explore bundles send it on every PPL query
disablePartialResults	the per-execution override threaded through executeQueries / executeHistogramQuery / executeTabQuery, plus the bucket-count carve-out that existed only to stop the denominator being undercounted
useRerunWithoutPartialResults	hook + test + barrel export
"Rerun without partial results"	the button, its i18n string, and the onRerunWithoutPartialResults prop through QueryWarningsCallout → ExploreDataTable / StatisticsTab

Kept

The warnings channel, end to end:

• ppl_search_strategy.ts still copies data.warnings onto dataFrame.meta.warnings
• QueryWarning stays in the results slice
• QueryWarningsCallout still renders one banner per warning, message always visible, detail behind "Show more", titling PARTIAL_RESULT as "Partial results" and anything else as "Warning"
• Both render sites keep it

So a backend that attaches a warning keeps its banner with no further Dashboards change.

Follow-up

With opensearch-project/sql#5814 merged, nothing produces a warning yet, so the banner won't show until these land (no further Dashboards change needed):

• Report a PPL result that covers only some of its shards sql#5807 reports a search that reached only some of its shards as PARTIAL_RESULT, which the banner titles "Partial results".
• Stop index pruning from dropping an index it could not reach sql#5819 stops index pruning from dropping an index it couldn't reach. Explore always sends a time range, which turns pruning on, so without it the warning is missed when a whole index is unreachable.

Upgrade note

explore:enablePartialResults ships in OSD 3.9.0 (#12481), paired with the engine side in opensearch-project/sql#5657. This PR and opensearch-project/sql#5814 remove it in 3.10, so users upgrading from 3.9 lose the setting:

• A value saved in 3.9 stays in the config object but is no longer read, so a user who turned it on gets complete results instead. SQL 3.10 no longer offers partial mode either.
• Mixed versions are safe. OSD 3.10 against SQL 3.9 stops sending partial_result, so the cluster default (off) applies. OSD 3.9 against SQL 3.10 still sends it, and the engine ignores it.
• If a 3.9.x backport comes up, take this PR and Remove the opt-in partial-result mode for mapping conflicts sql#5814 together.

Testing

node scripts/jest.js on the affected areas: 34 suites / 535 tests for state_management/actions and query_enhancements/server, plus 20 tests across query_warnings_callout, explore_data_table and statistics_tab — all passing. The callout's three rerun-specific cases are replaced by one asserting an unrecognised type still gets the generic "Warning" title. i18n-check and eslint clean. Two route tests check that a body carrying partial_result is accepted and that other unknown keys are still rejected.

Check List

• All tests pass
• New functionality includes testing — n/a, removal; the retained banner keeps its own tests
• Commits are signed per the DCO using --signoff
• Public documentation issue/PR created, if applicable — n/a, explore:enablePartialResults isn't on the documentation website

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 313ab4c)

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ No major issues detected

[github-actions]

Persistent review updated to latest commit 27be75e

[github-actions]

✅ All unit and integration tests passing

🔗 Workflow run · commit 313ab4cd05bcd7efe1aad9ca758ae842b77bf5fd

[github-actions]

Persistent review updated to latest commit f4402ef

[github-actions]

Persistent review updated to latest commit e9a5d80

[RyanL1997]

Thanks for the change @ahkcs . One high level thing need to confirm with you. It seems like there should be a follow up work after this change. Due to the removal of opensearch-project/sql#5814, plus this change, my understanding is that this banner will not be triggering at all at the moment.

May need to update the description with the info of your follow up work. But in general this is looking good to me.

[RyanL1997]

query has no unknowns option so it defaults to forbid, which means dropping this key makes a body that still carries it fail validation:

[partial_result]: definition for this key is missing

And the old client sent it on every PPL query, not just when the setting was on — the spread was keyed on language === 'PPL'. So a tab still running the old bundle 400s on every query until it reloads.

[ahkcs]

Confirmed. It 400s on every PPL query when the bundle and server report the same version (across a version bump, OSD's osd-version check rejects the stale tab first). Fixed in 943735a: partial_result is accepted and ignored, the rest of query stays strict, with tests for both.

[mengweieric]

This setting ships in 3.9.0, which releases on Sept 29. OSD 3.9 has #12481 and SQL 3.9 has opensearch-project/sql#5657, while opensearch-project/sql#5814 is only on main. So this PR removes an Advanced Setting that users will already have, which seems worth calling out in the description. If a 3.9.x backport comes up, taking this and opensearch-project/sql#5814 together keeps the two sides consistent. The documentation website has no mention of explore:enablePartialResults, so the docs item can be marked n/a.

[ahkcs]

Thanks, good call. Added an upgrade note to the description covering the 3.9 → 3.10 removal and pairing any 3.9.x backport with sql#5814, and marked the docs item n/a.

[mengweieric]

Nothing in StatisticsTab imports ../../application/hooks after this change, so this mock and the comment above it, which still describes the rerun action, can both go. The suite passes with the three lines removed.

[ahkcs]

Good catch, removed in 313ab4c. The suite passes without it.

[github-actions]

Persistent review updated to latest commit 943735a

[github-actions]

Persistent review updated to latest commit 943735a

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to 313ab4c

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Drop the redundant empty options argument Passing an empty options object is unnecessary noise now that disablePartialResults is gone. Omit the argument entirely so the function uses its default parameter, keeping the call site cleaner and consistent with the simplified signature. src/plugins/explore/public/application/utils/state_management/actions/query_actions.ts [672] } else { // Tab-specific: Create without aggregations - searchSource = await createSearchSourceWithQuery(preparedQueryObject, dataView, services, {}); + searchSource = await createSearchSourceWithQuery(preparedQueryObject, dataView, services); } Suggestion importance[1-10]: 2 __ Why: Minor stylistic cleanup; the empty object works fine with the default parameter and has no functional impact.	Low

---

Previous suggestions

Suggestions up to commit 943735a

Category	Suggestion	Impact
Possible issue	Avoid stubbing entire hooks module to empty The mock replaces the entire ../../application/hooks module with an empty object, which will break any other hook imported from it (e.g. useChangeQueryEditor) used by StatisticsTab or its children. Since the removed hook is no longer referenced, drop the mock entirely (or preserve the real module) to avoid hiding runtime failures in tests. src/plugins/explore/public/components/tabs/statistics_tab.test.tsx [23] -jest.mock('../../application/hooks', () => ({})); +jest.mock('../../application/hooks', () => ({ + ...jest.requireActual('../../application/hooks'), +})); Suggestion importance[1-10]: 6 __ Why: The suggestion raises a valid concern that mocking the entire ../../application/hooks module as {} could break other hooks imported from it. However, without knowledge of what other hooks StatisticsTab uses, the impact is uncertain, and the original PR intentionally simplified the mock.	Low

Suggestions up to commit 943735a

Category	Suggestion	Impact
General	Drop redundant empty options argument The empty options object is now redundant since createSearchSourceWithQuery defaults all options. Passing {} is harmless but the fourth argument can simply be omitted to match the function signature's default parameter and reduce noise. src/plugins/explore/public/application/utils/state_management/actions/query_actions.ts [672] } else { // Tab-specific: Create without aggregations - searchSource = await createSearchSourceWithQuery(preparedQueryObject, dataView, services, {}); + searchSource = await createSearchSourceWithQuery(preparedQueryObject, dataView, services); } Suggestion importance[1-10]: 2 __ Why: Minor stylistic cleanup; passing {} is harmless since the parameter has a default value. Very low impact.	Low

[ahkcs]

Thanks for the change @ahkcs . One high level thing need to confirm with you. It seems like there should be a follow up work after this change. Due to the removal of opensearch-project/sql#5814, plus this change, my understanding is that this banner will not be triggering at all at the moment.

May need to update the description with the info of your follow up work. But in general this is looking good to me.

Yes, no banner will be triggered for now, but we want to keep the warning channel for later follow-up PRs

I've updated the description on #12815. It now has a Follow-up section:

• sql#5807 makes the engine report a search that reached only some of its shards as PARTIAL_RESULT, which the banner titles "Partial results".
• sql#5819 stops index pruning from dropping unreachable indices. Without it, the warning is missed on Explore's time-range queries whenever a whole index is unreachable.

I also fixed a stale line: the description said partial_result was removed from the route schema, but after your earlier fix the route still accepts and ignores it. The Testing section now mentions the two route tests.

[github-actions]

Persistent review updated to latest commit 313ab4c