Chat recovery after a crash

DataMind Oda keeps each chat's record as a session log file on your computer, and it saves as the chat works. This page explains what happens when Oda stops suddenly, for example in a power cut or a forced restart: what was already saved, what gets repaired, and what you need to do. Where the files live is on Session logs on your computer; a chat that will not open because its log was written by another version is a different case, covered on Opening older chats.

What is already saved when the app stops

• Oda saves the chat's events durably before it moves on: before a request is sent to the model, before a command or another tool action runs, and at the end of each step, before the next request is built. Work that runs inside a command shares that command's save point.
• After a crash or a forced close, the chat reopens at the last point that was saved: everything up to it is kept, and anything after it is done again.
• The save points are part of how Oda runs. There is no setting that changes them.

The half-written end of a log

• If a stop lands in the middle of a save, the log can end with an incomplete record. When the chat is opened again, Oda opens it with every complete record and skips only the incomplete piece, with the note session "<id>" recovered from a torn tail; incomplete tail bytes were discarded.
• The next time the chat records something new, the incomplete bytes are cleared and the recovered records are saved again before the new ones.
• A compressed log is repaired the same way: the last compressed piece contributes only its complete records, and the incomplete part is skipped and cleared on the next save.

A turn interrupted by the stop

• A stop can leave the chat's last turn open. When the chat is opened again, Oda closes it without inventing content: the open step is ended, tool calls that had not finished are given error results, and the turn is closed as interrupted. The chat is then ready to continue.
• A call that had started, but whose result was never saved, is repaired with a result marked as an unknown outcome (TOOL_OUTCOME_UNKNOWN) and the note Do not retry blindly.: Oda cannot tell whether the action finished, so it checks what the action did before repeating it.
• A call that had not been recorded as started is repaired with a result marked as not started (TOOL_NOT_STARTED) and the note Retry it if it is still needed.: nothing was run, so the call can be asked again safely.
• Earlier messages stay as they were.

A command cancelled as it was being saved

• If you press Stop in the message box while Oda is still saving the step, before a command starts, the command does not run. Stopping a task is covered on Chat with Oda.
• The call is recorded as cancelled before dispatch (ABORTED_BEFORE_DISPATCH), and its result says Error: tool call aborted before dispatch. Nothing was executed, so you can ask again if you still need the action.

When a save cannot be written

• Oda refuses the step and the turn fails rather than carrying on from unsaved state. Retrying the request is safe.
• A failed save is put back the way it was before Oda reports the failure, so retrying cannot repeat what was already saved.
• If even that could not be done, Oda reports failed to roll back append to "<path>": the log may end with an incomplete piece, which the next open discards and the next write clears.
• A log changed outside Oda is refused rather than guessed at: for example, session "<id>": stored log shrank below a previously observed prefix (<n> < <m>) when the file is now shorter than the part Oda had already read.
• For the messages these cases can show, see Session log problems.

A damaged record in the middle of a log

A crash can also leave a damaged or out-of-order record in the middle of a log. When Oda reads such a log:

• It keeps the records before the problem and drops the damaged record together with anything after it that never completed.
• If a later finished turn shows that the region was committed, the problem is treated as damage: Oda refuses to open the chat rather than leave something out, and the file is not rewritten.

When another copy is holding the chat

A chat can be held for writing by only one copy of DataMind Oda at a time. When another copy holds it, for example because the desktop app and the web app are open side by side, the refusal carries the code session/writer-held and the app shows This session is already in use, possibly by another running DataMind instance (such as the web app or the desktop app). Quit the other running instances and try again. This is not damage to the log: quit the other copy, and the chat opens normally.

Branched chats and inherited calls

• When you branch a chat, the new chat marks the part of its history it inherited from the parent; how a branch is cut is on Conversation branches.
• If the inherited history shows a tool call that started but has no saved result, the branch records a repair for it with the note The parent session may have executed it after the fork point.: the parent chat may have run the call after the branch was cut, so the outcome cannot be known from the branch's record.

Questions, answered

How much of my chat survives a sudden stop?

Everything that was saved. Oda saves the chat's events before it sends a model request, before it runs a command or another tool action, and at the end of each step. The chat reopens at the last point that was saved, and anything after it is done again.

Why will the chat not open while another copy of Oda is running?

One chat has one writer at a time. When another copy of DataMind Oda, such as the desktop app or the web app, is holding the chat, the open is refused with session/writer-held and the app asks you to quit the other running instances. It is not a problem with the log: quit the other copy, then open the chat again.

Do I need to do anything to recover a chat?

No. DataMind Oda repairs the chat by itself when it is opened or continued; there is no recovery command and nothing to start.

Does a torn tail mean my chat is damaged?

No. It means Oda found an incomplete piece at the end of the chat's log, usually from a stop in the middle of a save. The chat opens with every complete record, and the next time it records something new the incomplete bytes are cleared.

What do the repair marks TOOL_NOT_STARTED and TOOL_OUTCOME_UNKNOWN mean?

They mark a tool call caught by the stop. TOOL_NOT_STARTED means the call had not been recorded as started, so nothing ran and it can be asked again safely. TOOL_OUTCOME_UNKNOWN means the call had started but its result was never saved, so Oda cannot tell whether it finished, and it checks before repeating the action.

Does recovery run my interrupted command again?

No. Recovery never repeats an interrupted call by itself. A call that had started is marked as an unknown outcome, and the note Do not retry blindly. tells Oda to check what the action did before repeating it.

After a crash, does Oda undo what a command had already changed?

No. Oda cannot tell whether a command ran or what it changed, so recovery does not undo anything. The call's outcome is marked as unknown, and Oda checks the action's effect before repeating it.

What is the note about the parent chat in a branched chat?

It is a repair note on a tool call the branch inherited without a result. The note The parent session may have executed it after the fork point. means the parent chat may have run the call after the branch was cut, so the branch cannot know the outcome from its own record.

Why did my turn stop when a save failed?

Oda will not carry on from unsaved state: when a save cannot be written, the step is refused and the turn fails instead of running half-finished. Retrying the request is safe, because a failed save is rolled back and cannot repeat events that were already saved.

Can I change how Oda saves and recovers chats?

No. The save points and the repairs are part of how Oda runs; there is no setting for them. For where chat logs live on your computer, see Session logs on your computer.

Is a compressed chat log recovered the same way?

Yes. With compression on, the last compressed piece contributes only its complete records; the incomplete part is skipped and cleared on the next save. Complete records are always kept.