[Security Solution][Bug] An error message is shown on searching case with its numeric incremental id.

[divyaaghi-qasource]

Describe the bug:
Upon searching the case with its respective incremental id, an error message is shown at the bottom right corner of the page.

Kibana/Elasticsearch Stack version:

VERSION: 9.3.0

BUILD: 94544

COMMIT: bf8c75b853e390db94045bdc41c8fc553ac848b9

Pre Conditions:
1.Kibana v9.3.0 snapshot should be running.
2.Different cases should be created.

Steps to reproduce:

1.Navigate to Security>More>Cases
2.On cases page, search the case by giving its respective incremental id .
3.Observe that upon searching an error message is shown on the bottom right corner of the page showing error fetching data.

Current behavior:
An error message is shown on searching case with its numeric incremental id.

Expected behavior:
No error message should be shown on searching case with its numeric incremental id.

Screen recording:

Get.started.-.Kibana.-.Google.Chrome.2025-12-16.15-01-57.mp4

Screenshot:

[elasticmachine]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[divyaaghi-qasource]

Suggestion to address the issue:

Version: Copilot- GPT-4.1:

High-level steps to apply:

• Add a small helper to normalize user-entered search text for KQL.
• Use that helper where the cases search input builds the search query before requesting cases.
• Run unit tests and functional tests for the cases plugin.

Files to modify / create

• Modify the case search component to normalize numeric-only tokens before calling the search API.
• Add a small helper util for the normalization.
• Patches (copy/paste into repo). Each file block below contains the file path relative to the repo.
• Add a helper util: x-pack/plugins/cases/public/common/utils/normalize_kql_search.ts
• x-pack/plugins/cases/public/common/utils/normalize_kql_search.ts
• If the whole search term or individual whitespace-separated tokens are numeric-only, quote them so KQL treats them as strings instead of numbers.
• This prevents KQL parsing/typing errors when users search for numeric incremental case ids
• (for example: 1, 23, 456) which are stored/indexed as strings in cases.
• Modify the search component that builds the query for listing cases. The exact component name and path can vary between Kibana versions; the following is the typical place to normalize the search string before requesting data. Example path: x-pack/plugins/cases/public/components/all_cases/search_bar.tsx
• x-pack/plugins/cases/public/components/all_cases/search_bar.tsx

Problem:

KQL/Kuery treats numeric tokens differently (as numbers) which may not match the case fields that are stored as strings, or it may cause parsing/typing errors in queries that expect strings. Searching "123" unquoted can produce an unexpected query which leads to the "error fetching data" toast.

Fix:

Quote numeric-only tokens so KQL treats them as string literals. This preserves normal behavior for non-numeric queries and for explicitly quoted tokens.

Testing & verification steps

After applying the changes, run the cases plugin unit tests:
yarn test:unit x-pack/plugins/cases
Start Kibana locally:
yarn start
Navigate to Security > More > Cases
Create/ensure there are multiple cases with incremental numeric ids
In the cases search box type a numeric id (for example "1" or "23") and press Enter or use the search icon.
Verify:
No "error fetching data" toast appears.
The case(s) with the matching incremental id appear in the results.

Notes / alternative approaches

Another option is to handle this in the server-side route that interprets the search query and defensively stringify numeric query tokens there. I preferred the client-side fix so that any KQL parsing/validation in the UI receives a safe query string. If you prefer server-side, add a similar normalization before constructing the Elasticsearch query.
This change is intentionally conservative: it only quotes tokens that are fully numeric and leaves other tokens untouched (and respects already-quoted tokens).

[divyaaghi-qasource]

@chetnarajput-qasource Kindly review!

[chetnarajput-qasource]

Reviewed and assigned to @vgomez-el