Unfinished assistant scaffold persists after prompt setup failure

[sowervids]

Description

The legacy prompt loop persists an assistant message before processor setup begins. Cancellation is handled, but a defect during the durable write, processor creation, or later turn setup can leave the message with no parts, no finish, no error, and no completion timestamp.

The same shape remains after a hard process interruption because no finalizer can run. It stays in session history as an unfinished assistant turn.

Expected behavior: exact empty scaffolds from prior executions should be marked interrupted before the loop continues, and every failed exit after scaffold creation should finalize the message without swallowing the original failure. Recovery must still allow the latest user prompt to receive a new response.

Plugins

None

OpenCode version

Current dev at 411eff73

Steps to reproduce

1. Create a session and persist a user message.
2. Persist an assistant message parented to it with zero parts and no finish, error, or time.completed.
3. Add a newer user prompt and run SessionPrompt.loop().
4. The newer prompt receives a response, but the old assistant remains permanently unfinished.

The future-failure path is reproducible by replacing SessionProcessor.create() with an Effect defect. The defect propagates, but the already-persisted assistant remains in the same unfinished state.

Screenshot and/or share link

Not applicable.

Operating System

macOS

Terminal

zsh

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Aborted assistant turn persisted with zero content bricks the session: empty assistant message replayed to provider (400 "must not be empty") #37946: Aborted assistant turn persisted with zero content bricks the session — overlapping concern about empty/unfinished assistant messages remaining in session history after an aborted turn
• Interrupted assistant messages retain non-error finish value (orphan tool-input-start abort) #33687: Interrupted assistant messages retain non-error finish value — directly related root cause: assistant messages left without a finish value after stream interruption

[sowervids]

I checked both suggestions. #37946 starts from an already completed errored turn with structural parts and concerns strict-provider serialization; #38270 targets that path. #33687 has an error plus tool state and asks whether provider finish should become error. This issue is the earlier scaffold state: zero parts, no error, no finish, and no completion timestamp after setup fails. The fix intentionally leaves finish provider-owned while recording an error and completion.

[sowervids]

Closing so this report can be resubmitted from the intended contributor account.