> ## Documentation Index
> Fetch the complete documentation index at: https://docs.honeyhive.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How to troubleshoot Conversation view

> Troubleshoot missing or incomplete HoneyHive Conversation view turns by checking model events, chat history, replies, and session links.

Use this guide when Conversation view is empty or does not show the turns you expect. Check the recorded model event first, then inspect the history and reply fields that Conversation view reads.

## Minimum data for a conversation

The `POST /v1/events` API requires `event_type` and an `inputs` object. Those fields make a valid event, but they do not guarantee a conversation can be displayed. Conversation view needs readable user or assistant content attached to the session you opened. To display a complete exchange, record both a user message and an assistant reply.

For a model event that records one exchange, include:

| Field | Value |
| - | - |
| `event_type` | `"model"` for the model call |
| `session_id` | The ID of the session where the conversation belongs |
| `inputs.chat_history` | An array of message objects with `role: "user"` or `role: "assistant"`. Use non-empty string `content` for readable text. Structured content can appear as JSON. |
| `outputs.content` | The assistant reply as a non-empty string. Replies in `outputs.result` or `outputs.text` also work when `outputs.content` is empty or absent. |

The user message and reply can be in one model event: put the user message in `inputs.chat_history` and the recorded reply in `outputs.content`. Include earlier assistant messages in `chat_history` when they are part of the recorded context.

This example uses the HoneyHive CLI to create a session, capture its ID, and post one model event. Install the CLI and configure `HH_PROJECT_API_KEY` first. Set `HH_DATA_PLANE_URL` only when you use a non-default Data Plane URL. See the [CLI getting started guide](/v2/cli-reference/getting-started), [session commands](/v2/cli-reference/ref/sessions), and [event commands](/v2/cli-reference/ref/events) for setup and options.

```bash theme={null}
# Create a session and capture its generated ID.
SESSION_ID=$(honeyhive sessions create \
  --session-name conversation-view-check \
  | jq -r '.session_id')

# Record one model event with a visible user message and assistant reply.
honeyhive events create \
  --event-type model \
  --session-id "$SESSION_ID" \
  --inputs '{"chat_history":[{"role":"user","content":"What does a session contain?"}]}' \
  --outputs '{"content":"A session groups related events from one interaction."}'
```

The API generates `event_id` when you omit it. If you omit `parent_id`, it defaults to `session_id`, so the event is attached directly to the session. After the minimum works, you can add optional timestamps, a model name, token counts, and nested events to provide more trace detail.

## Troubleshoot the message shown in the UI

| Conversation view says | What to check |
| - | - |
| "This trace has no model calls to display as a conversation." | Confirm that a real model call is recorded as `event_type: "model"` and that its `session_id` matches the session you opened. Tool-only traces can be valid traces, but they have no model call to display as a conversation. |
| "The recorded chat history could not be read as a conversation." | Put message objects in `inputs.chat_history`, give each visible message a `user` or `assistant` role and non-empty string `content`, and record the assistant reply in `outputs.content`. See the chain history guidance under Common instrumentation mistakes below. |
| "The structure of this trace could not be read as a conversation." | Compare the recorded events with the minimum data above. If the event structure looks correct and the issue persists, [contact support](mailto:support@honeyhive.ai) with the trace URL and sanitized event data. |

## Common instrumentation mistakes

If you omit `session_id`, ingestion creates a new session for the event, so the event does not appear in the session you opened.

Manual `POST /v1/events` requests do not convert `inputs.messages` or `outputs.choices` into the conversation fields. Put message objects in `inputs.chat_history` and the recorded assistant reply in `outputs.content`.

A serialized history string in place of the `inputs.chat_history` array, messages without roles, empty content, or a history made only of system or tool messages does not provide visible conversation turns. System prompts and tool results can still be useful in the trace, but they do not replace a readable user or assistant turn.

Check all chain events when model histories look correct. If any chain event in the session has an `inputs.chat_history` array, even an empty one, Conversation view reads turns from chain histories and recorded replies and ignores model event histories throughout the session. A chain with `chat_history: []` and no readable reply can therefore prevent a conversation from displaying even when readable model events sit beside it. Correct that history or remove it from the chain.

For the full view behavior, see [Thread View](/v2/tracing/thread-view). For manual event ingestion, see [Tracing via API](/v2/tracing/manual-instrumentation).


## Related topics

- [Thread View](/v2/tracing/thread-view.md)
- [Tracing via API](/v2/tracing/manual-instrumentation.md)
- [Troubleshooting & FAQs](/v2/introduction/troubleshooting.md)