# Check Repeated Provider-Turn Starts Without Replaying A Message

This page helps you confirm whether a Host saw a repeated provider-turn start
for the same user message, while keeping the original delivery from being sent
again. Use it when a conversation appears to reconnect, retry, or report the
same provider turn more than once and you need bounded local evidence.

Oysterun treats an exact repeat of the same provider turn as idempotent. The
first notice starts the delivery. A later matching notice preserves the
original start time, does not send a second request to the provider, and does
not move the delivery backward. A notice with different provider-turn identity
is treated as ambiguous and fails closed for that delivery instead of
terminating unrelated Host work.

## Before You Start

You need:

- access to the affected Oysterun Host as the owner or operator;
- the conversation still visible in the Oysterun app;
- permission to change the Host debug configuration and perform the
  owner-controlled restart that applies it;
- a short evidence window, so diagnostics can be turned off again after the
  event is captured; and
- a private place to store local diagnostic files.

Start from the conversation that showed the suspected retry or reconnect. The
message under investigation should still be visible, and the Host should be
reachable before you change any diagnostic setting.

## Start By Copying The Message Debug Details

Open the message menu for the message you want to investigate and choose
**Copy Debug Info**.

Checkpoint: the copied details identify the Host session, room, event, sender,
event time, and focus link for that message. Keep this information private. It
can identify a specific conversation and should not be pasted into public bug
reports, screenshots, or shared documentation.

If **Copy Debug Info** is unavailable, stop this path and first recover normal
message visibility in the app. Do not infer a provider-turn repeat from a
conversation screenshot alone.

## Enable The Diagnostic Flag

Open the Host debug configuration and preserve every existing setting. Add or
update this boolean key:

```json
{
  "debug_routec_host2_intake_diagnostics_enabled": true
}
```

The key must be a JSON boolean, not a string. Unknown keys or invalid values
can prevent the Host from accepting the debug configuration.

Apply the change through the normal owner-controlled Host restart procedure.

Checkpoint: after restart, the Host opens normally, the same conversation is
reachable, and no new delivery has been created merely by enabling the
diagnostic flag.

## Reproduce Or Wait For The Repeat

Return to the same conversation and wait for the suspected reconnect, retry,
or provider-turn repeat to occur. If the user action that triggers the issue is
safe to repeat, perform that visible action once.

Checkpoint: the conversation remains usable. An exact duplicate provider-turn
start does not create a second provider request for the same message. If the
provider identity conflicts, the affected delivery is held as ambiguous while
unrelated sessions continue running.

## Read The Diagnostic Record

Review the local Host diagnostic JSONL file for new rows from the evidence
window. Match the row to the copied debug details by Host session, room, and
Matrix event ID.

Useful outcomes include:

| Outcome | What It Means |
| --- | --- |
| `first_started` | The provider turn started normally for the first time. |
| `duplicate_idempotent` | The same provider turn repeated and was not replayed. |
| `terminal_duplicate_idempotent` | The repeat arrived after the delivery had already closed. |
| `canceled_preserved` | A late repeat did not resurrect a canceled delivery. |
| `identity_conflict` | The provider or provider-turn identity did not match and the delivery failed closed. |
| `invalid_state` | The notice did not fit the supported delivery state and failed closed. |

Checkpoint: the matching row explains whether the event was a safe repeat, an
identity conflict, or an unsupported state. Diagnostic rows contain bounded
identifiers and outcomes; they are not expected to contain prompts, message
bodies, provider output, credentials, cookies, tokens, or authorization
headers.

If no row matches the copied message details, do not treat the earlier failure
as proved by this diagnostic run. The event may not have repeated during the
evidence window, or it may belong to a different message.

## Disable Diagnostics

After the evidence window, preserve the other debug settings and set the flag
back to `false`:

```json
{
  "debug_routec_host2_intake_diagnostics_enabled": false
}
```

Apply the next owner-controlled Host restart.

Checkpoint: new intake diagnostic rows stop being written. Existing retained
diagnostic files are not deleted by disabling the flag.

## Recover Safely

If the Host does not accept the debug configuration, restore the previous JSON
and restart through the normal owner-controlled procedure. Then check the
configuration for a non-boolean diagnostic value, invalid JSON syntax, or an
accidental replacement of existing debug keys.

If the Host cannot open after restart, use the normal Host runtime recovery
path before collecting more diagnostics. Do not keep toggling the flag while
the Host is unavailable.

If diagnostic files grow during a long investigation, shorten the evidence
window and retain only the owner-approved local files needed for the support
handoff. Do not publish copied debug details or raw diagnostic rows unless the
conversation identifiers have been reviewed for privacy.