Log root search requests and partial resource stats on cancellation

[PSeitz-dd]

Summary

• Log root search requests on drop, including elapsed time and success/error/cancelled status.
• Emit root_resource_stats on success, planning/execution errors, and timeout cancellation.
• Retain resource stats as individual leaf responses arrive, before a subsequent error or cancellation can discard them.
• Report response coverage and partial/unavailable stats explicitly; omit unknown CPU timings rather than reporting zero.
• Document scope and limitations: in-flight/failed RPC work is unknown, and subsequent scroll pages do not emit this root event.

Validation

• make fmt
• git diff --check
• cargo nextest run -p quickwit-search: 214 tests passed
• Added tests for success, errors, timeout cancellation, and partial/missing stats.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 633a43ad50

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Capture resource stats before entering a retry

When ClusterClient::leaf_search receives a partial response, it performs its retry before this task.await completes. If the root request is cancelled during that retry, resource stats from the already-completed initial attempt are dropped and never reach the guard; similarly, an initial RPC error followed by a successful retry can be logged as complete even though the failed attempt's usage is unavailable. Record per-attempt responses inside the retry path so cancellation and completeness accounting include every finished attempt.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Create the root-search log guard before planning

When split planning returns an error or the request is cancelled while awaiting the metastore, execution leaves this function before RootSearchLogGuard is constructed. Those requests therefore emit no root_search completion event at all, contrary to this guard's stated cancellation behavior; construct the guard before starting the planning future and make the planning-dependent fields optional or update them afterward.

Useful? React with 👍 / 👎.