DatabaseConversationStore loses reasoningId/reasoningSummary when rehydrating ToolCall from DB

[nikitaku11]

Bug

When replaying conversation history that includes tool calls from a reasoning model, the OpenAI Responses API returns HTTP 400:

Item 'fc_xxx' of type 'function_call' was provided without its required 'reasoning' item: 'rs_xxx'.

Root Cause

DatabaseConversationStore::getLatestConversationMessages() reconstructs ToolCall objects from the database but omits the reasoningId and reasoningSummary fields:

// Current (broken)
new ToolCall(
    id: $toolCall['id'],
    name: $toolCall['name'],
    arguments: $toolCall['arguments'],
    resultId: $toolCall['result_id'] ?? null,
    // reasoningId and reasoningSummary are NOT restored
)

Both fields ARE serialized correctly via ToolCall::toArray() (which includes reasoning_id and reasoning_summary), so they exist in the database. They're just not read back.

As a result, every rehydrated ToolCall has reasoningId = null. Then in OpenAi/Concerns/MapsMessages.php, mapAssistantMessage() filters with ->whereNotNull('reasoningId'), so no reasoning items are emitted. The subsequent request then includes function_call items that reference reasoning items the API expects to be present, causing the 400.

Fix
Pass the stored fields when reconstructing ToolCall objects:

new ToolCall(
    id: $toolCall['id'],
    name: $toolCall['name'],
    arguments: $toolCall['arguments'],
    resultId: $toolCall['result_id'] ?? null,
    reasoningId: $toolCall['reasoning_id'] ?? null,
    reasoningSummary: $toolCall['reasoning_summary'] ?? null,
)

Steps to Reproduce
Use an agent with 'reasoning' => ['effort' => 'low', 'summary' => 'auto'] provider options
Complete a conversation turn where the model uses a tool
Send a follow-up message in the same conversation
Observe HTTP 400 from the OpenAI Responses API
Environment
Laravel AI package (laravel/ai)
OpenAI provider with reasoning models or models with reasoning enabled

[nikitaku11]

# Additional root causes found through debugging

Bug 1 — Wrong item order when replaying history (the main cause)
DatabaseConversationStore::getLatestConversationMessages() stores a single DB record containing both the final assistant text and all tool calls. When replayed, mapAssistantMessage() emits:

[role:assistant text]   ← emitted FIRST
[type:reasoning ...]
[type:function_call ...]
[type:function_call_output ...]

The OpenAI Responses API requires:

[type:reasoning ...]
[type:function_call ...]
[type:function_call_output ...]
[role:assistant text]   ← must come LAST, after the tool loop

Inserting a role:assistant message before the reasoning/function_call items causes the API to see the function_calls as orphaned from their reasoning context, even though the reasoning items are present.

Fix: Split the single DB record into three messages when loading:

// 1. Tool-calling turn — empty text, reasoning + function_calls only
new AssistantMessage('', $toolCalls->map(...))
// 2. Tool results
new ToolResultMessage(...)
// 3. Final text — AFTER the tool loop
new AssistantMessage($record->content)

Bug 2 — reasoning_id not captured during SSE streaming
In HandlesTextStreaming::processTextStream(), reasoning_id is assigned to a pending tool call at response.output_item.added time. However, $reasoningItems is only populated at response.output_item.done time — and in practice, output_item.added for the function_call can fire before output_item.done for the reasoning block, leaving $reasoningItems empty at assignment time.

Fix: If reasoning_id was not captured at output_item.added, fill it in at response.function_call_arguments.done time, when the reasoning block is guaranteed to be complete:

if (! isset($call['reasoning_id']) && filled($reasoningItems)) {
    $latestReasoning = end($reasoningItems);
    $call['reasoning_id'] = $latestReasoning['id'];
    $call['reasoning_summary'] = $latestReasoning['summary'] ?? [];
}

Bug 3 — summary: null produces invalid reasoning block on replay
MapsMessages::mapAssistantMessage() builds the reasoning block as:

['type' => 'reasoning', 'id' => $toolCall->reasoningId, 'summary' => $toolCall->reasoningSummary]

If reasoningSummary is null (e.g. no summary was returned by the API), summary: null fails OpenAI's schema validation. Use ?? [] as fallback.

All three issues can occur independently. Bug 1 is the most impactful since it affects every multi-turn conversation with tool use, regardless of whether the other two bugs are present.