llm: restore request logging lost in the agent-loop migration

The LLM-requests page has been empty since 24ee5b8: deleting `session/handler/llm_call.rs` dropped both halves of the request log. The kernel builds the `ModelRequest` itself and sets `log: None`, so the `LoggingModel` decorator — wrapped once per model by `LlmManager` — wrote every metadata row with a NULL `user_id`, while the page (and the detail endpoint) filter on it. Nothing wrote `llm_request_payloads` at all any more, so the payload viewer had nothing to show either. Correlation cannot come from `LlmManager`: it builds one shared client per model and does not know whose traffic it serves. It now comes from the `ModelSelector`, the one component that knows both the model and the owner: `SkaldSelector::with_log(RequestLogTarget)` wraps the model it hands out, so metadata lands in `llm_requests` attributed to the user and the payload lands in that user's own encrypted DB, keyed by `request_id`. Session and frame are read off the request's `conversation`/`frame`, which makes kernel rounds, sub-agent frames and compaction summaries all attributed with no extra plumbing (`ModelRequest::log` stays unused). The compactor's summariser call is attributed too, which it never was: `try_compact`/`force_compact` now take the owner (its selector is built per compaction, so it can carry the target). Three tests in `llm::logging` lock this down — the owner/session/frame columns, the error row with the provider's rejected body, and the metadata-only path when no owner pool is available. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 19:31:49 +01:00
parent a3e1b0add0
commit 73c720e9ef
9 changed files with 342 additions and 60 deletions
@@ -1,7 +1,9 @@
 //! DB operations for the `llm_requests` table (metadata only).
 //!
-//! Every `chat_with_tools` call is logged here by the
-//! [`crate::llm::logging::LoggingModel`] decorator.
+//! Every model call is logged here by the
+//! [`crate::llm::logging::LoggingModel`] decorator, which the caller's
+//! `ModelSelector` attaches to the model it hands out (that is where the owner
+//! of the traffic is known — `user_id` is what the UI filters on).
 //! Payloads (request/response bodies + headers) live in `llm_request_payloads`
 //! in the owner bucket (`{userid}.db`), correlated by `request_id`.
 //! Rows are retained for `llm.request_log.retention_days` days (default 14).