对于复用会话的决策链的展示，能否展示最初的决策是如何来的？

[aantior]

现在点击会话右边的http code，可以看到决策链。但是对于会话复用类型，只是一个会话复用其实没办法了解具体是什么原因选择的这个链路。
如果对于 会话复用类型，决策链不光写 会话复用，还写明白 这个会话session的一个会话的决策链就好了。

[github-actions]

Thank you for this feature suggestion.

Analysis

This is a well-identified gap in the current decision chain display. When a session is reused, the UI currently only shows "Session Reuse" with minimal context (session age, priority, cost multiplier), but does not show the original decision chain that led to the initial provider selection for that session.

Root Cause

The core reason is that when session reuse occurs, the system bypasses the full provider selection pipeline and only records a minimal decisionContext:

In src/app/v1/_lib/proxy/provider-selector.ts (lines 219-252), the session reuse path records:

session.addProviderToChain(reusedProvider, {
  reason: "session_reuse",
  selectionMethod: "session_reuse",
  decisionContext: {
    totalProviders: 0,  // Reuse skips filtering
    enabledProviders: 0,
    // ... minimal context only
  },
});

Meanwhile, the Redis session cache (session:{sessionId}:provider) only stores the provider ID as a plain integer (src/lib/session-manager.ts, lines 505-535), not the original decision context. The full providerChain (including the original decision chain) is persisted in the database's provider_chain JSONB column (src/drizzle/schema.ts, line 400), but only for the individual request that generated it.

How the UI handles it

Both display components explicitly skip the normal decision chain rendering for session reuse:

• provider-chain-popover.tsx (lines 117-194): Detects reason === "session_reuse" and shows only the violet link icon with session age/priority/cost info, skipping the selection funnel (total -> enabled -> healthy).
• LogicTraceTab.tsx (lines 79-93, 204-248): Detects isSessionReuseFlow and renders a "Session Reuse Selection" step card with session info, but sets decisionContext = undefined and filteredProviders = [], so the normal decision steps are not shown.

Feasibility Assessment

This feature is feasible. The original decision chain from the first request in a session is already stored in the database (message_request.provider_chain column). The key implementation considerations would be:

1. Backend: When recording a session reuse event, look up the first request in the same session (requestSequence === 1) from the database and attach its providerChain to the current session reuse context (e.g., as an originalDecisionContext field on ProviderChainItem).
2. Alternative approach: Store the original decision context in Redis alongside the provider ID when the session is first bound (in bindSessionToProvider), so it can be retrieved without a database query during session reuse. This would be faster but increases Redis memory usage.
3. UI: Update LogicTraceTab.tsx and provider-chain-popover.tsx to render the original decision chain when available on a session reuse item, perhaps as a collapsible "Original Selection" section below the session reuse info.

Affected modules

• src/app/v1/_lib/proxy/provider-selector.ts - Session reuse recording logic
• src/lib/session-manager.ts - Session-provider binding storage
• src/app/[locale]/dashboard/logs/_components/error-details-dialog/components/LogicTraceTab.tsx - Decision chain display
• src/app/[locale]/dashboard/logs/_components/provider-chain-popover.tsx - Compact chain tooltip
• src/types/message.ts - ProviderChainItem type definition (would need a new field like originalDecisionContext)

---

Automated response from Claude AI