Secured search logic to prevent runtime crashes on API errors

[Suraj704-glitch]

Secured search logic to prevent runtime crashes on API errors

Acceptance Criteria fulfillment

[x] Task 1: Wrapped the getSearchMessages API call in a try-catch block to ensure the application remains stable during server-side failures and network hiccups.

[x] Task 2: Implemented defensive rendering using Optional Chaining (?.) when accessing message counts, preventing the previously observed TypeError crash.

[x] Task 3: Validated the fix in the sandbox environment by simulating high-traffic search bursts and verifying the UI remains stable under API rate-limiting scenarios.

Fixes a runtime crash discovered during manual testing in #sandbox.

Screenshots

Before Fix :

The app crashes with a red-box TypeError when the API returns a 400 or 429 (Too Many Requests) error.

After Fix :

The UI remains stable and fully interactive. When an API error occurs, the app gracefully handles it and displays “No results found” instead of crashing.

PR Test Details

Environment: Launched the local dev environment using yarn storybook.

Testing Grounds:
Tested using channelName=general (without hardcoding roomId) to avoid environment-specific room identifiers.

Stress Test:
Manually spammed the search input to intentionally trigger API rate-limiting (HTTP 429).
Result:
API errors were logged as expected

The UI remained responsive and did not white-out or crash

Note:
The PR will be available for live testing at
https://rocketchat.github.io/EmbeddedChat/pulls/pr-1122

Once the PR is created/approved, contributors can replace #1122 with the actual PR number.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}